Ensure that bigger (breaking) changes and potential breaking candidates are better and earlier communicated in the Release Notes #995
Assignees
Labels
area/ipcei
Important Project of Common European Interest
kind/feature
new feature, enhancement, improvement, extension
Comments
jakobmoellerdev
added
the
kind/feature
github-actions
bot
added
the
area/ipcei
|
IMHO it's fine to generate the release notes as DRAFT, but publishing should be done only after HUMAN review and correction. |
jakobmoellerdev
added a commit
that referenced
this issue
Nov 4, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it part of release work on #995 We want to move away from component archives because we only really need the CTF as single source of truth. This makes the makefiles a little easier to understand and allows us to reuse these commands fairly easily in the next github actions reworks. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. -->
jakobmoellerdev
added a commit
that referenced
this issue
Nov 11, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it Part of the release rework (#995) that will allow us to move away from goreleaser for actual release work. This fully replaces the goreleaser workflow of updating the brew TAP with a PR that creates a versioned link in a PR towards the TAP repository. This allows - versioned brew installations like `brew install open-component-model/tap/[email protected]` instead of just the latest release - Allows us to run the goreleaser process without ever publishing any artifact externally #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. -->
hilmarf
pushed a commit
that referenced
this issue
Nov 11, 2024
…Z` (#1071) <!-- markdownlint-disable MD041 --> #### What this PR does / why we need it This reworks the release branch action to correctly branch off in patterns that do not include Z / Patch versions: ``` releases/v0.17.0 # before releases/v0.17 # after ``` To achieve this it allows to print only the major/minor combination for the release_generate.go generator. Additionally, it adds an automatic bump to main after the Branch Cutoff was completed into main. #### Which issue(s) this PR fixes Currently our release branches include the 0 Z / Patch version as part of their name, but this is misleading because we also use these branches for patches onto the Y / Minor version. This fixes up the release branch creation to 1. Create the Branch according to this pattern 2. Fixup the Main Branch with a Version Bump PR after the bump so that the next minor development can start. <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> part of #995 to ensure proper candidate creation
hilmarf
pushed a commit
that referenced
this issue
Nov 12, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it This fixes several inconsistencies with the release action and cleans it up before we are migrating some of the more substantial work within it: 1. main no longer gets release notes (as only release branches need to hold release notes) 2. The release version fetching and resolution is separated into a job just for this purpose, and can be reused across steps that need access to it 3. The draft release notes are now fetched via `gh` instead of the old `cardinalby/git-get-release-action@v1` because it is much faster and transparent what happens and the action wasn't maintained properly. 4. The `prerelease` flag was renamed to `release_candidate_name` to make it more clear for what it is actually used in the code. The existing docs on the action one can see when triggering them are unchanged 5. The `create_branch` option is killed because we dont expect the release to trigger the release branch creation, we expect that to come before. A separate PR can trigger the first release candidate creation from the Branch cutoff however (this will come separately) #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Part of the release process and transparency rework in #995
This was referenced Nov 12, 2024
jakobmoellerdev
added a commit
that referenced
this issue
Nov 15, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it This makes sure that we dont only do a patch bump on main after a successful branch cut, but we also do a bump on the release branch (for the next z / patch version) after the minor has been released. Creates a shared workflow that can be called from other workflows. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Ensures more automated workflows after the rework from #995 Example run at https://github.com/open-component-model/ocm-cicd-playground/actions/runs/11838213132/job/32986884073
hilmarf
added a commit
that referenced
this issue
Nov 21, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it This makes sure that the CTF is only built once in the release flow (during the components build) and then reused across the release. For this it needs to be built with the correct version during release (e.g. v0.18.0-rc.1) which we now pass via `EFFECTIVE_VERSION` into the Makefiles in the repo. This allows us to get rid of the `make CTF_TYPE=directory ctf` step in the goreleaser configuration so we now no longer need to build the ctf twice. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Part of the release candidate transparency rework in #995 as it allows us to prepare the release to only use the binaries from the CTFs. --------- Co-authored-by: Hilmar Falkenberg <[email protected]>
hilmarf
added a commit
that referenced
this issue
Nov 21, 2024
<!-- markdownlint-disable MD041 --> #### What this PR does / why we need it This documents the culmination of the work that has been ongoing as part of #995 It is an exhaustive rewrite of the Release Process documentation (albeit with 2 open points marked as TODO) that takes care of describing the new process of releasing through candidates via release branches. #### Which issue(s) this PR fixes <!-- Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> --------- Co-authored-by: Hilmar Falkenberg <[email protected]> Co-authored-by: Frederic Wilhelm <[email protected]>
|
We now notify of breaking changes correctly and we have them via separate category in the release notes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What would you like to be added:
Why is this needed:
The text was updated successfully, but these errors were encountered: