RFC: Python maintenance policy

Christoph Deil deil.christoph at googlemail.com
Tue Sep 23 00:57:59 PDT 2014


On 23 Sep 2014, at 04:46, Lawrence Velázquez <larryv at macports.org> wrote:

> 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.

Lawrence, thanks for doing this!

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

For Python 2.7 you could add a link to
http://legacy.python.org/dev/peps/pep-0373/#id2
which says that Python 2.7 will be maintained until 2020
and states that there will be no Python 2.8,
just in case someone reading the Macports Python maintenance policy doesn’t know.


> 
> ====================
> 
> 
> Comments welcome.
> 
> vq
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140923/a014827e/attachment.html>


More information about the macports-dev mailing list