[Biopython-dev] Deprecation and removal policy

[Bruce Southey]

On Fri, Nov 28, 2008 at 11:26 AM, Peter <biopython at maubp.freeserve.co.uk> wrote:
> Back on 27 June 2008, in preparation for what became Biopython 1.47,
> Michiel wrote:
>> In recent releases, we have been using the rule of thumb to remove all
>> modules from a new Biopython release that were deprecated two
>> releases ago.
>
> I was thinking that when we made releases about six months apart, this
> rule of thumb effectively gave a year's warning.  Recently we're made
> releases roughly every three months, which translates to only about
> six months warning, so I think we should be a little more restrained
> in removing deprecated code in future.
>
> As an example, Bio.EUtils was deprecated in favour of Bio.Entrez in
> Release 1.48 (Sept 2009).  Under the old rule of thumb, we could
> remove this module from CVS now (as the deprecation was present in
> Biopython 1.48 and 1.49).  If we release Biopython 1.50 in January or
> February 2009 (for the sake of argument), that means the deprecation
> would have been in place for only four or five months - which seems
> too rash.
>
> 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?
>
> Peter
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>

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.

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.

Bruce