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