I don’t get what’s wrong with the current system based on semver:
If you are actively developing the API, use 0.x.y.
If the API is kind of stable, use x.y.z.
Never make breaking changes in minor (y) releases.
Don’t tag a breaking release when there’s no breaking change.
The idea is that the pace of breaking releases in a 0.x.y package is closer to the pace of minor releases of a x.y.z package.
It’s just a rule of thumb. It helps everybody to roughly follow this but development is unpredictable and it’s not a huge deal if you get stable at 0.x.y, or move fast at x.y.z. But tagging a breaking release without breaking changes is way worse than releasing at an “unusual” pace.
Registrate and announce whenever it makes sense for your particular case. Just follow semver in terms of breaking releases.
yes, I agree that backporting fixes is easier when there’s x.y.z scheme;
However: until you want to commit to the first stable API (i.e. bump x from 0 to 1) there’s little benefit from this. You’re still developing and versions 0.y.z are precisely to tell your users that there’s no stable API you’re willing to support and maintain.
+1 for this. If you are registering a package, the expectation should be that you want other people to use and depend on it, in which case it should normally be 1.x. If an exception is needed in a particular case we can always manually merge into the registry.
I like this heuristic, and I fundamentally agree with the opinion that once it’s registered you have to assume users are depending on the API you export. My main concern with requiring v1 to release is the same as @tecosaur:
This seems like it could be alleviated if we had a way to designate in Project.toml that I want to instantiate a particular branch from a repo that I link to for CI/repo setup purposes. To keep this from bleeding into the general registry we could always forbid these types of dependencies when we tag releases
You could just not register if your code is very much in flux. It can still be used from the URL. But I would argue if your code is usable just register at 1.0, because you can always do 2.0 etc. And code changes (stable API) aren’t much of an issue if you pin versions.
Rick Hickey has a good talk arguing against semver. I.e. there should never be any breaking changes to software. That’s possible, he explains how… in that high-level (on of his many) excellent talk (which is not about Clojure or spec, or Java, or any specific language):
I haven’t yet watched this more specific talk about Clojure spec (I would like to know if we need something similar to spec, how the ideas translate to Julia if not specific syntax):
I’d be fine with registering even if the code is changing. Just respect semver. And registering with v1.0 does not mean you can’t make a lot of breaking changes after. There absolutely nothing wrong with having a package reaching some stability at version v96.0.
except users expecting you to maintain the API and backporting (that was the argument for doing it, right?) fixes; If I’m not willing to do so (yet), I signal this to my users by 0.x.y version;
That’s true, but only for end-of-the-line packages; Those packages there’s no reason to register before 1.0; However for a library you will need to ship Manifests to everything that depends on it (and update them accordingly). I’d argue that’s more work than adding compat for a non-breaking major release once;
And we’re hitting catch-22 problem here (as has been already noted by @jishnub): how do I know that the API reaches its stability when I severely limit the number of potential use-cases by not registering a package?
I don’t see that there is any requirement to backport; e.g. from 2.0 to 1.x. People my optionally backport (for some short while), and the Julia project would. Users of open source should expect anything (even for Julia, I’m just grateful). You’re free to release 0.x, possibly it will be a non-default way for registering, people can also declare “experimental” in docs.
What problem is this solving? With the current system people can choose if they want to add a 0.x dependency or not, with minimal friction. I think that’s a good thing and disagree in particular with this:
you want other people to use and depend on it, in which case it should normally be 1.x.
That’s only right for one “development style”, there are other valid styles. There’s nothing wrong with a package that’s heavily used while the API is evolving. DataFrames (before 2021), Makie, Turing… there are plenty of good examples.
Disabling automerge for v0 would be interfering with semver, and my guess is that would create problems rather than solve anything, by pushing people to declare v1 prematurely.
Firefox is not using semantic versioning, though, so I’m not sure how this is material to the present discussion?
I guess it’s clear that there are other versioning schemes beside semver out there, like Firefox’s:
. Starting with version 5.0, a rapid release cycle was put into effect, resulting in a new major version release every six weeks.
Maybe I shouldn’t do it but I tend to register “half-baked” packages. In the past I would refrain to do so but keeping packages unregistered makes them harder to discover, then people redo the same work several times, and packages are more likely to go unmaintained (there’s more pressure to keep your package working once it’s registered). On the other hand registering seems to have very little downsides.
If it’s indeed ok to register such package, it would still be good to have a way to indicate their are WIP, which 0.x.y seems to do. Maybe a badge/text in the README is enough though.
A recent example is these bindings for BWA, the package doesn’t do much, but it was still a bit of work to get working (interfacing with poorly documented c code) so I wouldn’t like someone to have to go through that again. Should I make a 1.0 release ?
I think it’s totally fine to register “half-baked” packages. This way other users can get involved and maybe also contribute.
As long it follows semver, everything will be okay, no matter if it’s version 0.x.y or version 102.4.1. There are many excellent solid packages out there at version 0.5.2 or something, so I don’t think a version < 1 is a real indication of anything. The only real test of stability is time. If you see package that has not had any breaking releases in a long time, but is still maintained that’s a good, real, sign that it’s reached some maturity.
I would add that the process of registering and keeping a fine control over versions is also a learning curve. For new contributors it feels more inviting learning all this with 0.X package versions.
My sensation is that creating a barrier for registering 0.X packages may create an impression that new packages are not that welcome unless in a very mature state. I would not take that route.
Encouraging people to register 1.X packages in a positive way is a more welcoming message.
EDIT: To be serious for a moment, I don’t want to create a breaking release for no reason. But I’ll definitely consider starting at 1.0 for the next package I register.
Logically: starting registered packages from 1.0 would be always preferable for the reasons discussed above.
Psycho-logically: especially for a less-experienced package author, having to register a not yet quite stable package at 1.x version feels like taking too much responsibility.
May be prevent automerging if either the package version is higher than e.g. 0.3, or if the package is already used by many other registered packages.
A zero-based versioning, e.g. ImageCore (started 2015, currently 384 dependent packages - current version 0.9.4), shouldn’t be the regular case.
