[Python-Dev] Versioning proposal: syntax.stdlib.bugfix (original) (raw)

Matt Joiner anacrolix at gmail.com
Sun Feb 26 04:22:54 CET 2012

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>

More information about the Python-Dev mailing list