release.md: cherry-pick ICINGA2_VERSION and CHANGELOG.md into master

[Al2Klimov]

ICINGA2_VERSION to keep snapshot versions newer than others and CHANGELOG.md to keep it in sync.

This substitutes ProBot functionality.

fixes #10016

[julianbrost]

This substitutes ProBot functionality.

ICINGA2_VERSION to keep snapshot versions newer than others

Did it ever do that?

[julianbrost]

and CHANGELOG.md to keep it in sync.

Also, doing this manually feels like quite a downgrade from the previous automatism. I'd rather try to find a solution where we can keep this.

[Al2Klimov]

I totally agree... with 1/2 of your opinion. Automatism is great. Depending on the frequency of the automated process. On its introduction that was like 10 times a day due to out of sync change logs. Now it would be once every several months.

[yhabteab]

I am not sure what I am supposed to be reviewing here, but isn't #10039 the kind of automation what @julianbrost is asking for? If that PR gets accepted, I see no reason why we should also do this.

[julianbrost]

There are two different things here:

• ICINGA2_VERSION: so far, this file isn't updated in the master branch which means git describe says something like v2.14.0-238-ga8adfeda6. In our package pipeline tooling, there's some special casing that fixes up the version number to something like icinga2_2.14.2+238.ga8adfeda6. This PR suggests updating that file on the master branch as well (which we don't do so far, at the moment, it still says 2.14.0). Determine Icinga 2 git version more reliably #10039 looks like it does something similar to what our package tooling currently does but within our CMake config.
• CHANGELOG.md: so far, when a release is done on a support/* branch, Probot will create a PR like CHANGELOG.md: add v2.14.2 #9972 so that this version also appears in the same file on the master branch. This PR suggests to make this a manual step in the release workflow, that's what I was referring to with "downgrade from the previous automatism".

[Al2Klimov]

[Al2Klimov]

and CHANGELOG.md to keep it in sync.

Also, doing this manually feels like quite a downgrade from the previous automatism. I'd rather try to find a solution where we can keep this.

• And Yonas did it manually: Add Icinga 2.14.* & 2.13.12 CHANGELOG.md to master #10470

[Al2Klimov]

I mean newer as in icinga2 --version

[yhabteab]

closes #10039

Why do you want to close that PR in favour of this one? That PR literally saves you this hole cherry-picking mess for nothing, and yet you just want to close it without even a bit of justification.

[Al2Klimov]

That PR literally saves you this hole cherry-picking mess

So it takes care for CHANGELOG.md? /s

I mean, if I cherry-pick the latter, I can also cherry-pick ICINGA2_VERSION right away.

[Al2Klimov]

ref/IP/56428