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

Terry Reedy tjreedy at udel.edu
Sun Feb 26 03:05:40 CET 2012


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



More information about the Python-Dev mailing list