My opinion is that we should not add any extra barrier to the General registry that is purely based on a version string. Software stability is a complex matter that is certainly not reflected by 2 or 3 numbers.
Even though I understand and appreciate @stevengj 's point that vx.y.z gives us 3 degrees of freedom as opposed to the 2 degrees of freedom of v0.y.z, it is still very useful to send the signal to potential users of a package that we are still in brainstorming phase and that many things can change over the years.
As @goerz pointed out, it is very difficult to work with unregistered packages in Julia, and so it is nice to be able to just register an experiment or prototype with v0.y.z to let other people depend on it and be aware of the risk. Semver is not new and we should just stick to it in my opinion. Trying to artificially create more v1.y.z packages in the ecosystem by making it more difficult to register v0.y.z will backfire on those who actually maintain and spend time developing experimental ideas.
That’s what I meant with my suggestion, i.e. from now on.
No, I looked at it and I don’t see it inconsistent with SemVer. Maybe I overlooked something (“breaking” is just mentioned in one place). I do not see any “MUST NOT” being violated.
What I do see:
Software using Semantic Versioning MUST declare a public API.
Ok, then 1.0 does that (instead of in Julia’s superset rules 0.x), there’s no requirement it’s breaking from 0.x.y, in SemVer. [Julia’s rules for 0.x.y are a superset of SemVer 2.0, I neither believe those rules violated, but I didn’t look at them.]
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
That rule doesn’t apply in Julia, as is.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
It must be incremented if there’s a breaking change, so updating it may imply a breaking change, but it’s not clear you MUST NOT increment otherwise.
Consider an old dependency ‘B’ that did a breaking transition 0.9 → 1.0, before your new semver came into practice. Suppose another package ‘A’ depends on ‘B’, but specifically on B v0.9 because they are not ready to adopt the new changes brought up by B v1.0. If now suddenly Pkg adopts a new definition of semver, where 1.0 is not breaking, this will break ‘A’ because it will start to depend on B 1.0 which it doesn’t really support.
Thanks for the additional explanations, I do think I understand the arguments, but I have strong reservations against creating friction for experimental, fast-evolving packages that are v0. The manual labor that is necessary to manually merge registry PRs would be better spent on more packages, or improving and consolidating existing packages.
For more mature packages that are still not past v1, the reason they aren‘t isn‘t solved by creating barriers/pressure of this kind. I don‘t think there is much value in moving to v1 for the smallest breaking change, which is what may be incentivized. What I meant was that I‘d like them to move to v1 while doing a big overhaul, such that they can hopefully stay there for a long time. If they can‘t, it‘s probably for lack of resources, and expending those resources to manually merge other package registrations won‘t help. If there is now an incentive to move to v1 just to avoid the manual merges, they would maybe do so for an insignificant breaking change, and they would now be stuck at v1 for the same reasons they were stuck before.
The “friction” would be a one-time cost per package similar to when a package has a slightly similar name to another package. This would not affect updates to to v0 packages.
Basically, we’re just asking a basic question at the initial package registration: “Are you should you want to register this package at v0?”.
Is most of this proposal just because semver is only three digits?
Just add a fourth digit for v0 releases.
v1 should be reserved for communicating that the package has been deemed to have a stable, solid API without major outstanding issues in its domain.
v0 packages that don’t go to v1 due to lack of developer time and attention shouldn’t just be promoted to v1 because they aren’t changing quickly. v0 or v1 should be a considered decision based on the state of the package, not done to conform to a rule, or for convenience.
Maybe, but surely easier and more sensible than reorienting the registry and current practices of hundreds or thousands of developers around it’s absence.
