-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release.md: cherry-pick ICINGA2_VERSION and CHANGELOG.md into master #9912
base: master
Are you sure you want to change the base?
Conversation
ICINGA2_VERSION to keep snapshot versions newer than others and CHANGELOG.md to keep it in sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This substitutes ProBot functionality.
ICINGA2_VERSION to keep snapshot versions newer than others
Did it ever do that?
@@ -20,6 +20,7 @@ assignees: '' | |||
- [ ] Create release on GitHub | |||
- [ ] Update public docs | |||
- [ ] Announce release | |||
- [ ] Cherry-pick update of `ICINGA2_VERSION` and `CHANGELOG.md` into master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two different things here:
ICINGA2_VERSION
: so far, this file isn't updated in themaster
branch which meansgit describe
says something likev2.14.0-238-ga8adfeda6
. In our package pipeline tooling, there's some special casing that fixes up the version number to something likeicinga2_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 asupport/*
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 themaster
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".
I mean newer as in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
ICINGA2_VERSION to keep snapshot versions newer than others and CHANGELOG.md to keep it in sync.
This substitutes ProBot functionality.
fixes #10016