[Biopython-dev] Deprecation and removal policy

[Peter]

Peter wrote:
>> ...
>> How about a new policy that after adding a deprecation warning,
>> deprecated modules/functions are kept for at least two public releases
>> AND at least 12 months (counting from the first release when they are
>> deprecated - not the date of the CVS change) before being removed?

Bruce wrote:
>
> Hi,
> Generally I would agree with idea for code that is under active
> development. For certain code that has not really been touched for a
> few years except for trivial changes (like removing string functions),
> I think 12 months is perhaps too long if it passes two releases.

Just because some (deprecated) code hasn't been changed in several
years doesn't mean no-one is using it.  Giving less warning for
removing such old but stable code isn't fair.

> Regardless of how it is done, Python 3 will need to be supported (the
> final release is due soon) and I do not see a reason to port
> depreciated modules or functions just because of some policy.  So I
> would add the provision that depreciated code will not be ported to
> the Python 3 compatible Biopython branch.

I disagree - dropping old modules is changing the API, counter to
Guido and other's recommendation/request: "Don't change your APIs
incompatibly when porting to Py3k."
http://www.artima.com/weblogs/viewpost.jsp?thread=227041

If porting any particular deprecated module or piece of code to Python
3 proved too difficult, then maybe we might drop that code (for
example, due to third party dependencies on an obsolete version of
mxTextTools, I don't think we'll port Martel/Mindy to Python 3).

Peter