[Python-Dev] Deprecation policy

[Nick Coghlan]

On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw <barry at python.org> wrote:
> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>
>>Well, that's why I think the version number components are not
>>correctly named. I don't think any of the 2.x or 3.x releases can be
>>called "minor" by any stretch of the word. A quick glance at
>>http://docs.python.org/dev/whatsnew/index.html should be enough.
>
> Agreed, but it's too late to change it.  I look at it as the attributes of the
> namedtuple being evocative of the traditional names for the digit positions,
> not the assignment of those positions to Python's semantics.

Hmm, I wonder about that. Perhaps we could add a second set of names
in parallel with the "major.minor.micro" names:
"series.feature.maint".

That would, after all, reflect what is actually said in practice:
- release series: 2.x, 3.x  (usually used in a form like "In the 3.x
series, X is true. In 2.x, Y is true)
- feature release: 2.7, 3.2, etc
- maintenance release: 2.7.2, 3.2.1, etc

I know I tend to call feature releases major releases and I'm far from
alone in that. The discrepancy in relation to sys.version_info is
confusing, but we can't make 'major' refer to a different field
without breaking existing programs. But we *can* change:

>>> sys.version_info
sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0)

to instead read:

sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0)

while allowing 'major' as an alias of 'series', 'minor' as an alias of
'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd
have started down the path towards coherent terminology for the three
fields in the version numbers (by accepting that 'major' has now
become irredeemably ambiguous in the context of CPython releases).

This idea of renaming all three fields has come up before, but I
believe we got stuck on the question of what to call the first number
(i.e. the one I'm calling the "series" here).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia