If you did, it was never tagged - you might want to tag it retroactively in case there is a new regression?
The development versions are never tagged. Only the stable versions are.
1 Like
I think you’re right, Magnus. But this makes me wonder if our versioning scheme is broken. Now that I look at history, we transitioned to the 2.45 series immediately after the 2.44.1 release. This means we’ll always end up with development versions that appear to be later than the upcoming release. Continuing like this will I think force us to always use even numbers for release, like you’ve suggested.
We are no longer using the even/odd versioning scheme so this is just a one-time event.
At this point we had not yet decided on the new versioning scheme although I had already (incorrectly) stated in the CHANGELOG that we adhered to semantic versioning.
Immediately after the 2.46.0 stable release, we will move to 2.46.1~dev, not 2.47.
What was incorrect was to move from 2.45. to 2.44.2~dev when we started the new versioning scheme, but there’s nothing we can we about that now and it just means that the development releases that we have made available since then seems to predate the 2.45 development releases that we made earlier.
OK, now I’m really confused… Referring again to the commit history, I can see you’re correct: at some point we switched from 2.45 to 2.44.2~dev. So even apart from the discrepancy with the 2.45 dev versions, is 2.45 already effectively a burned release version number?
I still don’t understand how the plan going forwards avoids this occurring again. If we transition to 2.46.1~dev following the 2.46.0 release we will immediately have dev versions that are numerically ordered after any upcoming 2.46.1 release.
(To bring up an old point that I’m sure has been explained to me before, why do we even have dev version numbers? Can’t we just use the commit hash as a version string?)
Yes. That’s why we need to go to 2.46.0.
No. Numerically they are equal. Both are 2.46.1. According to the semver spec however, 2.46.1~dev is a pre-release and compares less than 2.46.1 (although at the time of writing this, I cannot see that ~ is allowed instead of - for pre-releases. I have to get back on this. See also Version numbering going forward? - #16 by magjac).
Because we state that we follow semantic versioning which doesn’t allow it (although after following the discussions at GitHub - semver/semver: Semantic Versioning Specification for some time I’m starting to have second thoughts about the wiseness to do so).
Maybe this is the wrong way to think of it, but in my mind semantic versioning has nothing to say about version numbering of commits in-between releases. These intermediate points have no need for semver because users are not expected to install these and anticipate any kind of backwards compatibility. Case in point: we don’t bump the dev version for commits that break API; we only do this at release time.
I’m inclined to completely ignore semver in-between releases and use the Git commit hash. This makes it clearer to anyone using such a version that they’re on their own when it comes to determining backwards compatibility. It also removes the illusion that dev version numbers are comparable.
The RPM versioning constraints are a bit of a thorn. It’s a little perverse that we do these version number gymnastics to satisfy a packaging tool to build a package in CI that we don’t expect any end users to install. I have no easy solution to this. Just observing that the motivations for the current situation don’t really make sense.
If you want to continue the discussion about changing the version numbering scheme, I suggest we do it in Version numbering going forward?. If so, please also read what the semver spec has to say about pre-releases and be aware that we are making such releases (we call them development releases) at https://www2.graphviz.org/Packages/development/ that any user can install. I think you might again confuse these releases with development versions built by any user.
OK will do.