The version of the master is not the latest release

[gbin2265]

Describe the bug

When upgrading my test platform to the latest version I noticed that the version of icinga2 was different from the version stated in the rmp name

This is because the file ICINGA2_VERSION is still at version 2.14.0-1 and not at the last officially released version 2.14.2-1 But the name of the rpm is the 2.14.2-1.

icinga2.x86_64                     2.14.2+134.gd551eaea2-1708725810.el7
icinga2 --version    -> (version: r2.14.0-1)  

To Reproduce

Upgrade to the latest version of the snapshot and see which version you have with the command icinga2 --version

Expected behavior

Can you change the version of the master to the latest release version, the same as the one you also see in the name of the rpm. So that we as a tester see the correct version as stated in the rpm when using the icinga2 --version command after we installing the latest snapshot.

regards, Geert

[julianbrost]

Before going into details in any of the PRs[^1] created related to this, let me first explain the scope of this and how this was done historically and different approaches how this could be solved.

Scope

This actually is a broader topic than the issue described and what's considered in the existing PRs. Things that should be taken into consideration:

• Packaging vs. container images: for both deb/rpm packages and container images, version information is embedded into Icinga 2. That creates some weird dependencies: container builds are done completely independent of package builds, so anything done in the packaging wouldn't work for containers. The other way around it would be difficult as well as the package tooling should know the version of the package it builds before starting the build.
• I doubt this is really specific to Icinga 2. For Icinga DB, we avoided the problem so far by releasing all versions in a linear fashion (i.e. no bugfix releases for older support branches so far), but there's a good chance that this will happen in the future there. Also, Icinga Web probably has a similar issue, so how is it handled there? A common solution across our project would be desirable.

Historic approach

For the specific scenario described in this issue, this is actually a regression caused by the rework of our package tooling. Previously, it appended a file with the version number determined by the package tooling into the source tarball:

https://git.icinga.com/packaging/deb-icinga2/-/blob/a5e431be18333b6ffc8c7e3d31d8cc7e0ae3e5ee/get_snapshot#L81-85

Which is then picked up an used by our CMake config:

https://github.com/Icinga/icinga2/blob/27e1850381220ce3f997503bf0cae3dfc7cd1896/CMakeLists.txt#L111-L113

Our new packaging infrastructure just doesn't generate this file anymore.

Ideas

Just a bunch of ideas that could be worth considering:

• Quick fix for the described issue which actually is a regression: generate that icinga-version.h.force file for snapshot builds as it was done before, that mechanism is already there (but won't solve it for the container images)
• After releases, merge the branches into main/master as part of the release workflow. This would simply make git describe report a usable version number.
• Do some version number detection magic in CMake like proposed in #10039. Comes with the downside that the packaging tooling has similar logic that's duplicated.
• If there's duplication required, try to keep it to a minimum. One thing that could simplify things a bit: Take the current situation of the Icinga 2 repo with 2.14.5 being the latest release. Do we actually need to determine that .5 or would it be simpler to just say the current master branch is a version aiming to become 2.15.0, so use something like 2.15.0-dev-42-commitid as the version number.

[^1]: There are already multiple PRs, hence I'm writing this here, so that it gets lost in a PR that might be closed as we're choosing a different approach.