That is not necessary since the semver spec says A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
However, I’m in favor of bumping the minor version also for development versions when the first API happens, but not more than once between stable releases. My motivation for this bump is just that we shouldn’t forget it at the next stable release. It’s not mandated.
So, yes I agree that the current dev releases could be 2.46.0-dev, but not necessarily should unless we make that decision for ourselves that we should bump at the first API change (but only then).
I can’t argue with your reading of the semver spec, but to me this reinforces my thinking that the dev version numbers are useless. The numerical components are meaningless if they don’t actually indicate any compatibility. I’m still in favor of using commit hash for dev version numbers, though I don’t think we should change anything until some time after the 2.46.0 release dust has settled.
They are not meaningless since they are strictly ordered which means that they indicate more or equal functionality, fixes or other changes compared to the previous stable release and less than or equal to the next.
We still could change the current development version to 2.46.0~dev since according to semver 2.44.1 < 2.46.0~dev < 2.46.0, but we don’t have to since 2.44.1 < 2.44.2~dev < 2.46.0. It’s up to us which one we prefer.
I’ve been following the semver discussions for a while and it’s become clear to me that there are a lot of projects that have abandoned it because of the strict requirement to bump the major version when there’s a breaking change. These are almost always projects outside the npm/JavaScript world. If you use npm you will get into deep trouble if you don’t follow semver.
Since we’re not part of that world, I think there’s really no point for us to follow it strictly if we just stop declaring that we do and instead declare how we do instead. The reason I suggested it in the first place was just that I knew nothing better that was well documented.
I’m open for abandoning semver if it stops us from releasing breaking changes just because we don’t want to step the major version number. We just have to document such breaking changes carefully in the changelog.
Since Graphviz has been on version 2 for such a long time, I think people would be very disappointed if Graphviz version 3 hit the world and the only new thing was some technicality that broke the API without any substantial news.
I am actually in favor of keeping semver. It is no secret that I am no fan of semver. Nevertheless I do not want to cause yet more upheaval in the Graphviz world by changing some packaging detail yet again. Graphviz users have experienced too much churn to be subjected to yet another disruptive change like this.