<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 23 Sep 2014, at 04:46, Lawrence Velázquez <<a href="mailto:larryv@macports.org">larryv@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Maintaining old versions of CPython that aren't supported upstream is<br>annoying and a poor use of our time, so I'd like to propose<br>a maintenance policy. After we chit-chat about it, I'll write something<br>up on the wiki (hopefully a little clearer) and inform macports-users.<br></blockquote><div><br></div><div>Lawrence, thanks for doing this!</div><br><blockquote type="cite"><br>The term "replaced by" signifies using the "replaced_by" Portfile option<br>to obsolete a port.<br><br>The term "X.Y" refers to the CPython series in question.<br><br>The term "A.B" refers to the latest release on X.Y's development branch<br>*at the time of deprecation*. (The policy will ignore new upstream<br>releases made during the deprecation period.)<br><br>The term "M.N" refers to an arbitrary release between X.Y and A.B.<br><br><br>====== POLICY ======<br><br>The deprecation period for the X.Y series begins when the pythonXY port<br>is updated to the final upstream bugfix release and ends when the port<br>is replaced by pythonAB. Upstream security fixes may still be applied to<br>pythonXY during this period.<br><br>Once pythonXY is deprecated:<br><br> - New ports must not use pythonXY or create pyXY subports.<br><br> - After all dependents have been migrated, ports that use pythonXY<br> must switch to pythonAB.<br><br> - After all dependents have been retired, pyXY-foo ports must be<br> replaced by pyAB-foo. A pyXY-foo module that has been subsumed into<br> the A.B standard library must be replaced by pythonAB, although any<br> intermediate pyMN-foo ports may remain.<br><br> - Retired subports must be moved to a graveyard metaport so that<br> subsequent changes to their superports do not trigger spurious<br> failures on the buildslaves.<br><br>The pythonXY port is replaced by pythonAB one to two years after it is<br>updated to the final upstream bugfix release. At this point, the<br>deprecation period concludes, and the X.Y series is considered retired.<br><br><br>===== SCHEDULE =====<br><br>My short-term goal is to cut us back to the two most recent releases on<br>each CPython dev branch. Thus, the following series are deprecated and<br>will be retired on 1 January 2015:<br><br>- 2.4 series<br>- 2.5 series<br>- 3.1 series<br>- 3.2 series<br><br>The following series have also seen their final upstream bugfix release<br>and should thus be considered deprecated. They will be retired on<br>1 January 2016:<br><br>- 2.6 series<br>- 3.3 series<br><br>The following series seems to be undead and/or immortal. We'll pencil it<br>in for Ragnarok or thereabouts:<br><br>- 2.7 series<br></blockquote><div><br></div><div>For Python 2.7 you could add a link to</div><div><a href="http://legacy.python.org/dev/peps/pep-0373/#id2">http://legacy.python.org/dev/peps/pep-0373/#id2</a></div><div>which says that Python 2.7 will be maintained until 2020</div><div>and states that there will be no Python 2.8,</div><div>just in case someone reading the Macports Python maintenance policy doesn’t know.</div><div><br></div><br><blockquote type="cite"><br>====================<br><br><br>Comments welcome.<br><br>vq<br><br>_______________________________________________<br>macports-dev mailing list<br><a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br><a href="https://lists.macosforge.org/mailman/listinfo/macports-dev">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br></blockquote></div><br></div></body></html>