-
Notifications
You must be signed in to change notification settings - Fork 525
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
docs: clarify automation in release workflow #13851
docs: clarify automation in release workflow #13851
Conversation
This pull request does not have a backport label. Could you fix it @inge4pres? 🙏
NOTE: |
dev_docs/RELEASES.md
Outdated
@@ -72,7 +72,9 @@ For patch releases, only the version on the existing major and minor version bra | |||
|
|||
* A new [tag](https://github.com/elastic/apm-server/releases) will automatically be created on GitHub. | |||
|
|||
* Bump the version in anticipation of the next release, e.g. [after 8.13.3 release](https://github.com/elastic/apm-server/pull/13066) bump to 8.13.4. **Prepare this PR ahead of time** but only merge it once pinged by the Release Manager on release date. | |||
* Merge the PRs created by the GitHub workflow ran as part of the steps in the ["Day after feature freeze"](#day-after-feature-freeze) section. |
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 only applies to patch release, not minor release, right?
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 agree and this needs to be clarified as there are a lot of PRs involved in this process and as we discovered recently other PRs (docs + version bumps) must not be merged before release date.
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.
What do we need to do to clarify? Reach out to the robots?
This only applies to patch release, not minor release, right?
Good point, thanks for the callout. Should we make a distinction like we do above for minor/patch release?
E.g. say: "for minor releases, merge this and that; for patch releases, merge this other and that other PR".
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 think the old bullet point was correct, no? Basically on the release day the next patch version bump has to happen, everything else is supposed to already be done by the day after feature freeze or the day before release.
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.
It depends how we structure the flow, I think.
The old doc assumed the version bump PR is created on FF, and merged on release day.
I don't see why a time distance between the 2 events should exist, and I see more risk in creating and merging a PR for version bump before we are requested to do so (as we would produce a DRA version that is too early).
That's why I added the "IMPORTANT" section below, but I also agree that the previous phrasing was more correct.
I'll amend that
@inge4pres Do the changes still apply? Do you want to hand this PR over to @1pkg ? |
dev_docs/RELEASES.md
Outdated
This workflow will: create the release branch; update version across codebase; commit and create PR targeting the release branch. | ||
Release notes for patch releases **must be manually added** (PR should target `main` branch and backported to the release branch): | ||
This workflow will: create the `update-<VERSION>` branch, update version constants across the codebase and create a PR targeting the release branch. | ||
Release notes for patch releases **must be manually added** (PR should target `main` branch and should be backported to the release branch): |
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 would add here must be manually added a day before release
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.
Teams do it on either D-1 or release day. I think it is fine to specify it as D-1 here for clarity.
dacb6d9
to
2e011b1
Compare
Amended the phrasing as suggested, trying to see how the preview renders the important block |
works with latest commit |
Signed-off-by: inge4pres <[email protected]>
Signed-off-by: inge4pres <[email protected]>
Co-authored-by: Carson Ip <[email protected]> Signed-off-by: inge4pres <[email protected]>
Signed-off-by: inge4pres <[email protected]>
Signed-off-by: inge4pres <[email protected]>
96d0743
to
e3911a2
Compare
Signed-off-by: inge4pres <[email protected]> Co-authored-by: Carson Ip <[email protected]> Co-authored-by: Kostiantyn Masliuk <[email protected]> (cherry picked from commit a813495)
Signed-off-by: inge4pres <[email protected]> Co-authored-by: Carson Ip <[email protected]> Co-authored-by: Kostiantyn Masliuk <[email protected]> (cherry picked from commit a813495) Co-authored-by: Francesco Gualazzi <[email protected]>
Motivation/summary
During the 8.15 release cycle we noticed some differences between what documented as needed and the available tooling for release.
This Pr is an attempt to clarify what's documented.