[Python-Dev] Deprecation policy (original) (raw)

Matt Joiner anacrolix at gmail.com
Wed Nov 30 06:26:27 CET 2011

I like this article on it:

http://semver.org/

The following snippets being relevant here:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

With the exception of actually dropping stuff (however this only occurs in terms of modules, which hardly count in special cases?), Python already conforms to this standard very well.

On Wed, Nov 30, 2011 at 11:00 AM, Benjamin Peterson <benjamin at python.org> wrote:

2011/11/29 Nick Coghlan <ncoghlan at gmail.com>:

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.versioninfo is confusing, but we can't make 'major' refer to a different field without breaking existing programs. But we can change: sys.versioninfo sys.versioninfo(major=2, minor=7, micro=2, releaselevel='final', serial=0) to instead read: sys.versioninfo(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). Can we drop this now? Too much effort for very little benefit. We call releases what we call releases. -- Regards, Benjamin

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com

More information about the Python-Dev mailing list