# Timeline for releasing Graphviz 2.44.2 **URL:** \ **Category:** Dev\ **Created:** [October 10, 2020, 11:04pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381 "2020-10-10T23:04:55Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![schmoo2k](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/schmoo2k/32/29_2.png) [@schmoo2k](https://forum.graphviz.org/u/schmoo2k)\ **Post date:** [November 7, 2020, 3:55pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/21 "2020-11-07T15:55:52Z")
If you did, it was never tagged - you might want to tag it retroactively in case there is a new regression? ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 7, 2020, 3:58pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/22 "2020-11-07T15:58:50Z")
The development versions are never tagged. Only the stable versions are. ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 7, 2020, 4:12pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/23 "2020-11-07T16:12:12Z")
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. ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 7, 2020, 4:33pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/24 "2020-11-07T16:33:17Z")
We are no longer using the even/odd versioning scheme so this is just a one-time event. > [@smattr](#): > > Now that I look at history, we transitioned to the 2.45 series immediately after the 2.44.1 release. 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. ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 7, 2020, 4:39pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/25 "2020-11-07T16:39:11Z")
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. ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 7, 2020, 4:50pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/26 "2020-11-07T16:50:42Z")
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?) ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 7, 2020, 5:59pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/27 "2020-11-07T17:59:31Z")
> [@smattr](#): > > is 2.45 already effectively a burned release version number? Yes. That’s why we need to go to 2.46.0. > [@smattr](#): > > 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. 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](https://forum.graphviz.org/t/version-numbering-going-forward/237/16)). > [@smattr](#): > > why do we even have dev version numbers? Can’t we just use the commit hash as a version string? 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](https://github.com/semver/semver) for some time I’m starting to have second thoughts about the wiseness to do so). ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 7, 2020, 7:49pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/28 "2020-11-07T19:49:12Z")
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. ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 8, 2020, 10:57am UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/29 "2020-11-08T10:57:40Z")
If you want to continue the discussion about changing the version numbering scheme, I suggest we do it in [Version numbering going forward?](https://forum.graphviz.org/t/version-numbering-going-forward/237). If so, please also read what the [semver spec](https://semver.org/) 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/](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. ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 8, 2020, 4:48pm UTC](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381/30 "2020-11-08T16:48:58Z")
OK will do. [Previous page](https://forum.graphviz.org/t/timeline-for-releasing-graphviz-2-44-2/381.md?page=1)