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
