Version numbers
Jakub Ružička
jakub.ruzicka at nic.cz
Mon Jan 15 14:06:43 CET 2024
Hey,
On 1/12/24 13:08, Ray Bellis wrote:
> Hi BIRD folks!
>
> Could you please consider using consistent semantic versioning in your
> release numbers? (see semver.org)
>
> Up until 2.13 all releases used the x.y.z format, with a trailing .0
> for the first release in each minor release. However the the 2.13 and
> 2.14 releases did not - they just used x.y
Yes, let's talk about this.
Semantically, I consider 2.13 to be a shortcut for 2.13.0 but they
aren't the same version from package manager point of view:
$ dpkg --compare-versions 2.13 eq 2.13.0 && echo true
$ dpkg --compare-versions 2.13 lt 2.13.0 && echo true
true
so 2.13 < 2.13.0
PATCH bumps (on MAJOR.MINOR.PATCH version string) would now look
2.14 -> 2.14.1 -> 2.14.2 -> ...
This introduces two versions string cases x.y and x.y.z where there
could (should) only be one. This inconsistency will continuously bring
problems and/or extra parsing logic in places where it wouldn't be
necessary with consistent format.
I recommend always using x.y.z version format as Ray suggests. This
convention is also used in most projects I packaged including Knot DNS
and Knot Resolver.
> This broke our deployment code that uses semantic version aware checks
> to tell whether the running daemon is not the same as the available
> package.
>
> A formally adopted (and documented) version numbering policy would be
> of great use to system administrators.
I completely agree. BIRD got closer to semver with the recent versioning
change (2.13 instead of 2.0.13) and adding the trailing .0 would align
it with how most projects do versions thus minimizing unwanted surprises
such as this one.
Cheers,
Jakub Ružička
CZ.NIC packager
More information about the Bird-users
mailing list