Re: RFC: Python maintenance policy
Maybe not new py24-foo or new py25-foo ports, but what about +python24 or +python25 variants for ordinary ports that have python bindings? For example, this isn't the port itself, but from reading the upstream gdb mailing lists, it looks like gdb upstream actually extended their support for python backwards to python24 with their most recent release this summer (7.8), whereas before they had only supported back to python26... On 9/23/14, Andrea D'Amore and.dam...@macports.org wrote: On Tue, Sep 23, 2014 at 4:46 AM, Lawrence Velázquez lar...@macports.org wrote: == POLICY == […] The policy is informally half in place, noone is actually creating new py24-foo or py25-bar (or at least I hope soo), that said I'm glad to see old py* ports being phased out. This could be handled by the python** portgroups that are already in place after defining stable-version (or latest-stable) variable in the main portgroup. -- Andrea ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
On Tue, Sep 23, 2014 at 4:46 AM, Lawrence Velázquez lar...@macports.org wrote: == POLICY == […] The policy is informally half in place, noone is actually creating new py24-foo or py25-bar (or at least I hope soo), that said I'm glad to see old py* ports being phased out. This could be handled by the python** portgroups that are already in place after defining stable-version (or latest-stable) variable in the main portgroup. -- Andrea ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
On Tue, Sep 23, 2014 at 6:49 AM, Sean Farley s...@macports.org wrote: it's because of Python 3 screwing up the treatment of unicode strings. sarcasm It's spelled improved. /sarcasm I'm liking py3 insofar. -- Andrea ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
On Tue, Sep 23, 2014 at 12:49 AM, Sean Farley s...@macports.org wrote: 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. Huh. I'd assumed arm-twisting from Red Hat, possibly with an education about enterprise support windows. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
Brandon Allbery writes: On Tue, Sep 23, 2014 at 12:49 AM, Sean Farley s...@macports.org wrote: 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. Huh. I'd assumed arm-twisting from Red Hat, possibly with an education about enterprise support windows. Here is a good article that outlines the frustration with unicode for python libraries: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
On Sep 23, 2014, at 3:49 AM, Andrea D'Amore and.dam...@macports.org wrote: The policy is informally half in place, noone is actually creating new py24-foo or py25-bar (or at least I hope soo) Yup. Most of it really is just common sense. I just want to formalize it for the future, so we have something to point to when we say No You Should Not Do This Anymore. This could be handled by the python** portgroups that are already in place after defining stable-version (or latest-stable) variable in the main portgroup. Some of it can be handled in portgroups, but not all of it. For instance, deprecated subports really should be moved into separate metaports to keep the buildslaves from going crazy. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
On 23 Sep 2014, at 04:46, Lawrence Velázquez lar...@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
RFC: Python maintenance policy
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 The following series seems to be undead and/or immortal. We'll pencil it in for Ragnarok or thereabouts: - 2.7 series Comments welcome. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
