[Python-Dev] PEP 413: Faster evolution of the Python Standard Library

[Brett Cannon]

On Fri, Feb 24, 2012 at 13:23, Georg Brandl <g.brandl at gmx.net> wrote:

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

Ditto. You could also mention that this could help other VMs by getting
compatibility fixes into the stdlib faster than they do currently, letting
other VMs hit minor release compat faster.


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


While I personally would rather switch to making the major version mean a
language change has occurred instead of reserving it for completely
backwards-incompatible language changes, I know history is going to lead
people killing that idea, so I agree with Georg on using an LTS delineation
for language-changing releases and keeping them patched up until the next
LTS is better. IOW we cut 3.3.0 as an LTS and then have 3.4 and 3.5 only
contain stdlib changes while also releasing 3.3.1 and 3.3.2 for bugfixes on
3.3. There would be no micro releases for 3.4 and 3.5 (sans an emergency
brown bag release) since the next release is coming in 6 months anyway with
any previous bugfixes + changes that might break compatibility with 3.3 in
the stdlib.

My worry with Antoine's approach is that it will cause pain for people by
us mucking around with stdlib stuff that will break compatibility somehow,
preventing some people from upgrading immediately, but out in the cold when
it comes to bugfixes since they can't grab the next release yet. The only
way for Antoine's approach to work is if we made some release count
guarantee (like 3 releases) for anything that might break someone, making
stdlib-only releases more accumulative then iterative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120224/2cbcf0eb/attachment.html>