Deprecation cycle

[Steve Purkis]

Hi all,

I've just written this in the HACKING.pod -- seems sensible to me,  
though I'm not sure if everyone agrees with it:

------------------
=head1 Deprecation cycle

Any I<documented> sub that needs to be changed or removed (and would  
therefore
cause a backwards-compat issue) must go through a deprecation cycle  
to give
developers a chance to adjust:

   1. Document the deprecation
   2. Release
   3. Change the code
   4. Release
------------------

Also, in TAP::Parser/SUBCLASSING:

------------------
=item 4

By subclassing, you may end up overriding undocumented methods.   
That's not
a bad thing per se, but be forewarned that undocumented methods may  
change
without warning from one release to the next - we cannot guarantee  
backwards
compatability.  If any I<documented> method needs changing, it will be
deprecated first, and changed in a later release.
------------------

If people don't agree, now's the time to take these out.

-Steve