Re: Python 3.6 in stretch
Adam Borowski <kilobyte@angband.pl> writes:
> On Tue, Jan 10, 2017 at 05:35:34AM +1100, Ben Finney wrote:
>> Galbo is referring correctly to the minor version, as specified in
>> <URL:https://www.python.org/dev/peps/pep-0440/> and Semantic Versioning
>> <URL:http://semver.org/>.
>> So, “3.5.3” → “3.5.4” is a change of patch version. “3.5” → “3.6” is a
>> change of minor version. And “2” → “3” is a change of major version.
> Not every project uses semver.
> In some, like Perl, Python, GNOME, when the first number changes you have
> a different language/DE.
Also, semver has a tendency to "degrade" in older, huge packages like
Python or Perl. When the language first started, the first version was
the major version for breaking changes, and the second version really was
a minor version. But both kept using the major/minor split from the early
days of the package as it became more and more widely used, making what
were originally minor changes much more disruptive since, by now,
*someone* is relying on every odd corner of the language.
You see this a lot in packages like this. The first version number
essentially becomes fixed and changes to the second number are as big of a
transition as changes to the first number used to be, even though the
changes are relatively more minor, because the exposed surface area and
the number of depending packages is so much larger.
If you want to stick with the "amount of integration work required"
implications of semver, at some point in the lifespan you have to mentally
change gears and start using major version changes for things you'd
previously only used minor version changes for. Most packages never do
that. (I think GCC has, but it's a relatively rare exception.) There's a
lot of mental resistance to doing so because it implies the change is
somehow larger than the changes that one did with just minor version bumps
in the past.
And, of course, with Python, it's much too late to make that mental shift
now, since Python 2.x and Python 3.x now mean something specific and
people would expect Python 4.x to be just as disruptive as the 2.x to 3.x
migration.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: