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 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. thanks, Ray
Hello Ray and list, thank you for pointing at this. We actually intend to do kinda the semantic versioning, we only didn't see any reason to add a trailing zero. Regarding your case, I'd suggest to _not_ rely on the versioning being x.y.z; what we can promise (and probably should document) is that every new version is lexicographically after any older one and doesn't contain whitespace. We can even promise that it matches the regex [0-9.-a-z]+ … but not much more – if you ever get in a situation where you need to check a development version due to some bug, you're screwed with strict x.y.z checks. Also please note that we are not doing strictly the semantic versioning as it is described on the website, there are some differences, notably in what is considered a reason to bump the major version number. Have a nice weekend! Maria On 2024-01-12 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
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.
thanks,
Ray
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
In another context outside of this list, I was confused on the version numbering as well, where I ran 2.0.x version, and someone else ran 2.y, with y > x. A small bit of digging revealed the following paragraph in the NEWS file (see for example <https://gitlab.nic.cz/labs/bird/-/blob/7d2c7d59a363e690995eb958959f0bc12445355c/NEWS#L45-50>): Notes: We changed versioning scheme from <epoch>.<major>.<minor> to more common <major>.<minor>.<patch> . From now on, you may expect that BIRD 2.13.x will be strictly only fixing bugs found in 2.13, whereas BIRD 2.14 will also contain new features. This was also announced on this list at the release of 2.13 (2023-04-23). However, in a rather long range of x.y.z-like versions (with a somewhat different approach than semantic versioning), it does seem odd to leave out the .z-part on a new minor release, some 4 months after the last release. I suppose a small note of "on release of a new minor version, we leave out the '.<patch>' part" would help a lot for understanding the versioning system. If lexicographical sort is indeed the way to go, then it would also be nice to have the download page <https://bird.network.cz/?download> reflect that sort. At this moment, '2.13.1' is sorted before '2.13'. This may apply for other pages as well. Best regards, Gerdriaan Mulder On 13/01/2024 22:57, Maria Matejka via Bird-users wrote:
Hello Ray and list,
thank you for pointing at this. We actually intend to do kinda the semantic versioning, we only didn't see any reason to add a trailing zero.
Regarding your case, I'd suggest to _not_ rely on the versioning being x.y.z; what we can promise (and probably should document) is that every new version is lexicographically after any older one and doesn't contain whitespace. We can even promise that it matches the regex [0-9.-a-z]+ … but not much more – if you ever get in a situation where you need to check a development version due to some bug, you're screwed with strict x.y.z checks.
Also please note that we are not doing strictly the semantic versioning as it is described on the website, there are some differences, notably in what is considered a reason to bump the major version number.
Have a nice weekend! Maria
On 2024-01-12 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
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.
thanks,
Ray
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
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
participants (4)
-
Gerdriaan Mulder -
Jakub Ružička -
Maria Matejka -
Ray Bellis