4 ms·

... thats stupid. Semver isn't that complicated, and everyone understands what 3.10 means.

cwyers 11y ago
Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not having precognition made it difficult for Python to adopt SemVer, and now that they have versioning practices in place there needs to be more than "I like SemVer" as a compelling argument for them to change. Especially since there are reasonable people who have reasonable disagreements with how SemVer works.
- mikestew 11y ago
  I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes. It probably goes back further than that, and it was probably one of those "everybody knows..." kind of things, but it definitely didn't start to be a widely-known definition a measly seven years ago.
  - plorkyeran 11y ago
    There were a lot of projects informally using what semver defined, but there were also a lot of other popular versioning schemes. Odd minor = unstable version, even minor = stable version used to be pretty popular and is still used by a few projects. The main thing that helped make SemVer the default assumption was package managers that baked it into the dependency resolution, as until then a project's versioning scheme really didn't matter very much to the users of the project as long as it wasn't completely incomprehensible.
    - jrochkind1 11y ago
      Well, baking it into dependency resolution is a response to the fact that figuring out if there were breaking changes in any given update becomes intractable as your dependency tree/graph gets large (and multi-levelled), when each dependency uses it's own versioning scheme, no matter how comprehensible they are individually.
- jrochkind1 11y ago
  The argument for semver is obviously "you should be able to tell if there are breaking changes between two versions from the version numbers", not "I like semver". You may or may not be persuaded by it, but that's the point of it.
takluyver 11y ago
There's code even in the stdlib which gets the major version by doing strversion[:3] , so it would see 3.10 as 3.1. That could be fixed, but who knows where else that assumption has been made.
- theptip 11y ago
  There's also code that's going to break `if sys.version_info[0] is not in (2, 3)`, as the article points out -- so bugs are going to need to be fixed either way.
theptip 11y ago
This. Why would you gratuitously change the major version of a language, if there are no back-incompatible changes? Everyone understands what 3.100 means, too.
gh02t 11y ago
He might have been just using that as a rough number for example purposes. Python does use semver loosely (effbot.org/pyfaq/how-does-the-python-version-numbering-schemae-work.htm). I expect there probably will be at least some breaking changes in 4.0 or at least major new additions to warrant the major version bump, but I think they want to avoid anything that makes migrating code/libraries anything more than trivial for the majority of users. For 2->3 stuff like print as a function was straightforward, but other stuff like lazy range() or the Unicode strings would actually require people to make significant changes, which stagnated migration.
dang 11y ago
> thats stupid Please don't do this here. From the site guidelines: When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Semver isn't all that OLD; it came out in 2009, I think? (The SemVer site very helpfully doesn't have any dates on it.) Python, meanwhile, came out in 1991. Not having precognition made it difficult for Python to adopt SemVer, and now that they have versioning practices in place there needs to be more than "I like SemVer" as a compelling argument for them to change. Especially since there are reasonable people who have reasonable disagreements with how SemVer works.

mikestew 11y ago
I have nothing to back this up other than my increasingly unreliable memory, but the semantics of SemVer goes back further than 2009. Maybe it wasn't formally written out, but as far back as the 90s that XX.YY.zz could be translated as XX == major changes, breaking changes for APIs, reworked UI for end-user apps. YY == some new functionality, no breaking/major changes. zz == bug fixes. It probably goes back further than that, and it was probably one of those "everybody knows..." kind of things, but it definitely didn't start to be a widely-known definition a measly seven years ago.
- plorkyeran 11y ago
  There were a lot of projects informally using what semver defined, but there were also a lot of other popular versioning schemes. Odd minor = unstable version, even minor = stable version used to be pretty popular and is still used by a few projects. The main thing that helped make SemVer the default assumption was package managers that baked it into the dependency resolution, as until then a project's versioning scheme really didn't matter very much to the users of the project as long as it wasn't completely incomprehensible.
  - jrochkind1 11y ago
    Well, baking it into dependency resolution is a response to the fact that figuring out if there were breaking changes in any given update becomes intractable as your dependency tree/graph gets large (and multi-levelled), when each dependency uses it's own versioning scheme, no matter how comprehensible they are individually.
jrochkind1 11y ago
The argument for semver is obviously "you should be able to tell if there are breaking changes between two versions from the version numbers", not "I like semver". You may or may not be persuaded by it, but that's the point of it.

takluyver 11y ago

There's code even in the stdlib which gets the major version by doing strversion[:3] , so it would see 3.10 as 3.1. That could be fixed, but who knows where else that assumption has been made.

theptip 11y ago
There's also code that's going to break `if sys.version_info[0] is not in (2, 3)`, as the article points out -- so bugs are going to need to be fixed either way.

theptip 11y ago

This. Why would you gratuitously change the major version of a language, if there are no back-incompatible changes? Everyone understands what 3.100 means, too.

gh02t 11y ago

He might have been just using that as a rough number for example purposes. Python does use semver loosely (effbot.org/pyfaq/how-does-the-python-version-numbering-schemae-work.htm). I expect there probably will be at least some breaking changes in 4.0 or at least major new additions to warrant the major version bump, but I think they want to avoid anything that makes migrating code/libraries anything more than trivial for the majority of users. For 2->3 stuff like print as a function was straightforward, but other stuff like lazy range() or the Unicode strings would actually require people to make significant changes, which stagnated migration.

dang 11y ago

> thats stupid Please don't do this here. From the site guidelines: When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html