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