Adam Borowski <kilob...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
