On Thu, Sep 1, 2011 at 3:36 AM, Mike Meyer
On Wed, Aug 31, 2011 at 10:23 AM, Guido van Rossum
wrote: (*) Can we pick a terminology so we all agree that "3.3.3" is a "minor release", "3.3" is a "major release", and "3" an "earthshattering release"? Or other terms -- but something that is both agreed upon and clear enough without explanation. I'm tired of having to clarify minor and major every time I use them out of fear they'll be mistaken for "3" and "3.3".
Given that there's no general industry agreement on what those things mean, "clear enough without explanation" is probably unrealistic. On the other hand, a PEP or some similar document that lays out the terminology used for python releases (and encouraged for python libraries) would let you assume that python people had read that explanation, and make a reference to it easy (i.e."see PEP XXXX").
That PEP is PEP 101 (at least as far as Python releases go), and it is currently a little inconsistent (using major.minor.micro in some sections, as the devguide and sys.version_info apparently also do, but also referring to feature releases as major releases on at least one occasion). PEP 386 (which aims to standardise version numbering within the wider Python ecosystem) doesn't mandate a naming scheme (only a numbering one), but does refer to the major.minor.micro names in the explanatory text. Personally, I agree with others that "feature release" and "bug fix release" are as close as we're likely to get to unambiguous names for the way Python itself uses x.y and x.y.z release numbering. Creating a new version of the language itself is rare enough that I don't think it really needs a generic name. Although with the accumulated baggage that 3.0 swept away, "spring cleaning release" might be appropriate :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia