[Python-Dev] Versioning proposal: syntax.stdlib.bugfix

[Matt Joiner]

Chrome does something similar. All digits keep rising in that scheme.
However in your examples you can't identify whether bug fixes are to stdlib
or interpreter?
On Feb 26, 2012 10:07 AM, "Terry Reedy" <tjreedy at udel.edu> wrote:

> We have two similar proposals, PEPs 407 and 413, to speed up the release
> of at least library changes. To me, both have major problems with version
> numbering.
>
> I think the underlying problem is starting with a long-term fixed leading
> '3', which conveys no information about current and future changes (at
> least for another decade).
>
> So I propose for consideration that we use the first digit to indicate a
> version of core python with fixed grammar/syntax and corresponding
> semantics. I would have this be stable for at least two years. It seems
> that most current syntax proposals amount to duplication of current
> function to suite someone's or some people's stylistic preference. My
> current view is that current syntax in mostly good enough, the
> implementation thereof is close to bug-free, and we should think carefully
> about changes.
>
> We could then use the second digit to indicate library version. The .0
> library version would be for a long-term support version. The library
> version could change every six months, but I would not necessarily fix it
> at any particular interval. If we have some important addition or upgrade
> at four months, release it. If we need another month to include an
> important change, perhaps wait.
>
> The third digit would be for initial (.0) and bugfix releases, as at
> present. Non .0 bugfix releases would mostly be for x.0 long-term
> syntax+library versions. x.(y!=0).0 library-change-only releases would only
> get x.(y!=0).1 bugfix releases on an 'emergency' basis.
>
> How this would work:
>
> Instead of 3.3.0, release 4.0.0. That would be followed by 4.0.1, 4.0.2,
> etc, bugfixes, however often we feel like it, until 5.0.0 is released.
>
> 4.0.0 would also be followed by 4.1.0 with updated stdlib in about 6
> months, then barring mistakes, 4.2.0, etc, again until 5.0.0.
>
> A variation of this proposal would be to prefix '3.' to core.lib.fix. I
> disfavor that for 3 reasons.
> 1. It is not needed to indicate 'not Python 2' as *any* leading digit
> greater than 2 says the same.
> 2. It makes for a more awkward 4 level number.
> 3. It presupposes a 3 to 4 transition something like the 2 to 3
> transition. However, I am dubious about for more than one reason (another
> topic for another post).
>
> --
> Terry Jan Reedy
>
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> anacrolix%40gmail.com<http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120226/463302da/attachment.html>