[Python-Dev] PEP 413: Faster evolution of the Python Standard Library (original) (raw)
Georg Brandl g.brandl at gmx.net
Fri Feb 24 19:23:36 CET 2012
- Previous message: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library
- Next message: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 24.02.2012 18:46, schrieb Antoine Pitrou:
Hello, On Sat, 25 Feb 2012 03:24:27 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: To allow the PEP 407 authors to focus on making the case for doing full CPython releases every 6 months (including language spec updates), I've created PEP 413 as a competing proposal.
It leaves the current language versioning (and rate of change) alone, while adding an additional date based standard library version number and adopting a new development workflow that will allow "standard library" releases to be made alongside each new maintenance release. Overall, I like the principle of this PEP, but I really dislike the dual version numbering it introduces. Such a numbering scheme will be cryptic and awkward for anyone but Python specialists.
I agree.
I also think the branches and releases management should be even simpler:
- 2.7: as today - 3.3: bug fixes + stdlib enhancements - default: language enhancements / ABI-breaking changes Every 6 months, a new stdlib + bugfix release would be cut (3.3.1, 3.3.2, etc.), while language enhancement releases (3.4, 3.5...) would still happen every 18 months.
Sorry, I don't think that's feasible at all. For one, it removes the possibility to target a stable set of features for a longer time.
In short, the only usable solution I see is PEP 407-style versioning with language changes only in LTS releases.
Georg
- Previous message: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library
- Next message: [Python-Dev] PEP 413: Faster evolution of the Python Standard Library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]