RFC: Python maintenance policy

[Sean Farley]

Lawrence Velázquez writes:

> Maintaining old versions of CPython that aren't supported upstream is
> annoying and a poor use of our time, so I'd like to propose
> a maintenance policy. After we chit-chat about it, I'll write something
> up on the wiki (hopefully a little clearer) and inform macports-users.
>
> The term "replaced by" signifies using the "replaced_by" Portfile option
> to obsolete a port.
>
> The term "X.Y" refers to the CPython series in question.
>
> The term "A.B" refers to the latest release on X.Y's development branch
> *at the time of deprecation*. (The policy will ignore new upstream
> releases made during the deprecation period.)
>
> The term "M.N" refers to an arbitrary release between X.Y and A.B.
>
>
> ====== POLICY ======
>
> The deprecation period for the X.Y series begins when the pythonXY port
> is updated to the final upstream bugfix release and ends when the port
> is replaced by pythonAB. Upstream security fixes may still be applied to
> pythonXY during this period.
>
> Once pythonXY is deprecated:
>
>   - New ports must not use pythonXY or create pyXY subports.
>
>   - After all dependents have been migrated, ports that use pythonXY
>     must switch to pythonAB.
>
>   - After all dependents have been retired, pyXY-foo ports must be
>     replaced by pyAB-foo. A pyXY-foo module that has been subsumed into
>     the A.B standard library must be replaced by pythonAB, although any
>     intermediate pyMN-foo ports may remain.
>
>   - Retired subports must be moved to a graveyard metaport so that
>     subsequent changes to their superports do not trigger spurious
>     failures on the buildslaves.
>
> The pythonXY port is replaced by pythonAB one to two years after it is
> updated to the final upstream bugfix release. At this point, the
> deprecation period concludes, and the X.Y series is considered retired.
>
>
> ===== SCHEDULE =====
>
> My short-term goal is to cut us back to the two most recent releases on
> each CPython dev branch. Thus, the following series are deprecated and
> will be retired on 1 January 2015:
>
> - 2.4 series
> - 2.5 series
> - 3.1 series
> - 3.2 series
>
> The following series have also seen their final upstream bugfix release
> and should thus be considered deprecated. They will be retired on
> 1 January 2016:
>
> - 2.6 series
> - 3.3 series

Sure, that all sounds fine.

> The following series seems to be undead and/or immortal. We'll pencil it
> in for Ragnarok or thereabouts:
>
> - 2.7 series

I actually have the back story for this from the last PyCon. Suffice to
say, it's because of Python 3 screwing up the treatment of unicode
strings.