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" 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@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** anacrolix%40gmail.comhttp://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com

On Sun, Feb 26, 2012 at 12:05 PM, Terry Reedy wrote:

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

In updating PEP 413 to include an explanation for why the simple major.minor.micro = language.stdlib.maintenance approach doesn't work due to the ongoing 2->3 transition [1], I realised that there *is* a way to make it work: Instead of making 3.3 version 4.0, we make it version 33.0 That's essentially what PEP 413 currently proposes for the standard library anyway, but it would actually work just as well for the existing sys.version_info structure. (it would break "sys.version_info.major == 3" checks, but such checks are badly written) [1] http://www.python.org/dev/peps/pep-0413/#why-not-use-the-major-version-numbe... Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia