That said, SemVer does have flaws. Bundler, npm , Rust’s Cargo, NuGet, and a variety of tools have implemented the specification. But there are edge cases, as well as gaping holes, in the spec, and so in some ways, these tools are incompatible.
Over the last few months, several of us2 have been talking, and today, we have an announcement to make. We’ve formed a semver team, and we intend to start work on producing a new version of the spec.
Who is “we”? The team roster will be in a GitHub team3, but for posterity’s sake, here’s the initial list of members, in the same order GitHub lists them:
Anand Gaurav, NuGet
Dave Herman, Notion
André Arko, Bundler
isaacs, npm
Samuel Giddins, CocoaPods
Steve Klabnik, Cargo
I assume this effort has some relevance to us, hence my posting this here. Perhaps someone from the Python community should be involved in this group?
Python doesn’t use semver so it’s not directly related to us so I don’t know that they’d necessarily want us on the group (or that we would have much in the way of useful input from our experiences in Python’s packaging).
The question of if we should continue to use PEP 440 or we should try to transition to SemVer is a different, much harder question I think.
I’m thinking there will be people start trying the new scheme out on Python packages, and be unhappy if the current scheme isn’t compatible with the “new” semver.
It might be a good idea IMHO to keep an eye on how the new version will look like, maybe make reasonable modifications to the allowed version string scheme to keep it compatible if possible, or probably provide early feedback to avoid a disaster.
Off topic, but can anyone point me some directions what Notion is? I recognise all other package managers in the list (I assume it is also one?), and a quick Google search gave me nothing relevant.
You mean CPython doesn’t? A lot of Python packages use semver and probably will want to continue to do so. I can’t imagine that it’s completely irrelevant to have someone from Python reach out who was involved in PEP 440 and/or may be involved in updating it to allow users to use whatever this new semver will be. Can’t hurt to offer up a sacrifice delegate.
I believe it’s related to dependency management in JavaScript. Dave Herman is a coworker of mine. I’m trying to get a canonical public reference to the project, and will post a followup if/when I get that.
No, I mean Python’s packaging tools don’t support SemVer generally as a rule, we support PEP 440. Now it so happens that there is overlap between a valid SemVer version and a valid PEP 440 version so if an individual project wants to do something SemVer-esque they can… by restricting themselves to the subset of grammar that both PEP 440 and SemVer supports.
Example: Here’s a version directly from the SemVer spec that is invalid in PEP 440: 1.0.0-x.7.z.92, and likewise 1.0.dev0 is a valid PEP 440 version, but an invalid SemVer version.