Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/ISSUE_TEMPLATE/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Contributor

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 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".


## Update Bundled Windows Dependencies

Expand Down
Loading