I’ve become a fan of pretty early on in a package’s development going to v1.X.X so that you have more flexibility in SemVer. This gives you a little bit more flexibility for how it impacts dependencies from the get-go.
Yep.
I start all packages at v1.0.0
It’s now the default in PkgTemplates.jl
9 Likes
Interesting. We should relegate v0 to indicate pre-registration status. Perhaps package registration should only automerge packages at v1 into the registry?
6 Likes
I don’t quite understand what’s the point of versioning packages which are not in (some) registry;
To me version 0.x.y simply means
- the package is not yet in the finished (=complete) state, BUT
- the authors are willing to use it anyway, and
- they are happy if people go out and battle-test it as well.
If one is not using actively a package and sees no real use for external users (or is not happy with them using it) then why even register (and bump versions, etc)?
@oxinabox why is starting at 1.0.0 any better than 0.1.0? (especially with julia provision on semver?)
+1 to this.
Just remove all the special Julia semver provisions for 0.x.y (except maybe for already registered packages). Would be simpler, IMHO.
1 Like
Because a 0.y.z package has only two levels available: breaking and non-breaking. x.y.z packages can differentiate two non-breaking levels, where z is patches and y is features. Before 1.0.0 you cannot tell what kind a release is.
10 Likes
I don’t quite understand what’s the point of versioning packages which are not in (some) registry;
There is none, normally. Potentially one might have internal use cases for it, like some set of milestones before release.
That’s one of the arguments for why we should start at 1.0.0.
Semver 2 (without the Julia extension) says that you should go to v1.0.0 as soon as you begin distributing the software, which in Julia-land means registering the package.
The others include what @gustaphe said:
Because a
0.y.zpackage has only two levels available: breaking and non-breaking.x.y.zpackages can differentiate two non-breaking levels, wherezis patches andyis features. Before1.0.0you cannot tell what kind a release is.
and also that people forget the julia extension and mistakenly take a release that is nonbreaking as 0.x.0 because it adds new features.
And finally, the one that motivates this whole discussion thread:
if you start at 1.0.0 you don’t need to make a breaking release when you realise the package is done at v0.7.4
12 Likes
Do I understand the argument made here correctly that:
- people should start registering packages at 1.0
- let’s say one publishes a package to obtain usage and user feedback to identify API problems before becoming stable.
- In vanilla semver, those would be a succession of 0.* releases.
- In julia-flavour semver, and following the above recommendation, after, say, 4 api-correcting (breaking) releases, you end up with e.g. 5.4 where you consider the API “done”. Correct?
As a comparative julia “newbie”, i find this confusing, and I think it loses the "signalling effect of package version 1.0 a bit:
Version 1.0.0 defines the public API.
4 Likes
Can you point out which part of semver says that? I found that bit surprising, and just re-read the definition, and could not find a passage that I would interpret this way? 
It’s been a bit since i read it, and i mangled it slightly by here is the relevant bit
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
For open-source libraries users immediately depend on your API.
I guess you could argue if your users are not really depending on your package for anything important … but that’s out of your hands in open-source.
I have argued a few times that we should have a Unstable registry which allows people to register stuff pre-1.0.0, and allows them to depend on other unstable things, or things from General. TBH I don’t care that much.
7 Likes
To me, when you’re looking for feedback on the API you should be distributing the repo url, registering is making an API commitment. Not a permanent one, but that’s what major versions are for.
1 Like
That’s a catch-22 situation, since the feedback one seeks often only arrives after other packages have tried to use it as a dependency, and that will only happen once the package is registered.
5 Likes
This is an interesting tangent to me, because I have a trio of packages that depend on each other and are in active “breaking change every few commits” development. For them I’m feeling that v0.x development is working quite well. They are going to reach a point where I’m happy with the design/API within the next few months. Without registering them getting the docs build/tests to work would have been quite a bit more hassle.
I think linking announcing a package for use and tagging 1.0 should go together, but it’s useful to have 0.x packages registered.
2 Likes
What’s the difference between realizing “the package is done” at v0.7.4 (if started with v0.1) versus at v7.4 (if started with v1)?
I don’t see anything practical aside from having two non-major version numbers.
1 Like
I think this is overrated. We should only distinguish breaking vs. non-breaking changes. The “signalling effect” of a package’s stability will come automatically, as the amount of time it stays still without new breaking releases.
Just this.
I don’t see anything practical aside from having two non-major version numbers.
The other reason I forgot, is the reason why having two nonbreaking version numbers is actually really important.
It allowed backporting fixes.
Since new features, including change of compatibility with other packages, lead to a 1.x.0 release
there is space to back-port bug fixes into any of the patch release numbers.
This means if you have users locked out of using the latest release because of incompatibility with dependencies, you can still back-port fixes for them.
We used to do this a lot at Invenia.
One team would be moving the latest version of the API ahead, breaking compatibility etc as needed to use latest tools.
while another team worked on a system that used that library on the old API to accomplish some goal.
And then bug-fixes could be sent back to the users versions ago.
You see this a fair bit for Julia itself.
Backporting bugfixes to the LTS.
10 Likes
I get the arguments, but at the same time, I like how Julia did it. One breaking release per year from 0.1 to 0.7, then using 1.0 as a “this is stable / ready” marker. Otherwise, how would you do it? Julia 1.0 to 7.0 as “beta”, then you make a big party for Julia 8.0? Wouldn’t feel the same.
5 Likes
I would say it’s not fair to compare Julia the language itself, to how we should treat packages.
Consider that before v0.6 (I think) there was no Pkg (as we know it today, with Project.toml and so on) and how versions were resolved was different , etc.
2 Likes