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.

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

Introduce a standardized mechanism for patch releases #207

Closed
2 tasks done
mlavacca opened this issue Apr 23, 2024 · 2 comments
Closed
2 tasks done

Introduce a standardized mechanism for patch releases #207

mlavacca opened this issue Apr 23, 2024 · 2 comments
Assignees
Milestone

Comments

@mlavacca
Copy link
Member

mlavacca commented Apr 23, 2024

Problem Statement

We need a mechanism to backport fixes into release branches and cut releases without manually branching out and backporting all the needed contributions. We already have a similar mechanism in KIC that we could easily reuse here.

Proposed Solution

Reuse the same pipelines we already have in KIC to backport fixes and release patch versions on top of already existing releases.

Acceptance Criteria

  • the Backport workflow allows to backport fixes through labels, fixed by chore: backport workflow added #237
  • the release procedure is updated with instructions on how to release minor and patch releases and the differences between them.
@pmalek
Copy link
Member

pmalek commented Apr 26, 2024

KIC has backport workflow which has the problem of conflicts (these mostly happen when there's a change in CHANGELOG).

It would basically be a copy-paste of the workflow but that would still has this issue and require manually backporting in case of conflicts. There is no such feature ( to exclude changes from a provided path(s) in the action that we use https://github.com/tibdex/backport ). So we either fork it an implement ( possibly too much effort ) or leave with the flawed workflow of manual backporting in case of conflicts.


As for the patch releases: I'm not aware of any process/automation that we'd have in place for KIC's release branch. Those are pushed manually whenever we decide to branch off, no?

@mlavacca
Copy link
Member Author

KIC has backport workflow which has the problem of conflicts (these mostly happen when there's a change in CHANGELOG).

It would basically be a copy-paste of the workflow but that would still has this issue and require manually backporting in case of conflicts. There is no such feature ( to exclude changes from a provided path(s) in the action that we use https://github.com/tibdex/backport ). So we either fork it an implement ( possibly too much effort ) or leave with the flawed workflow of manual backporting in case of conflicts.

Yep, at least for now I'd simply copy-paste the workflow we already have in KIC.

As for the patch releases: I'm not aware of any process/automation that we'd have in place for KIC's release branch. Those are pushed manually whenever we decide to branch off, no?

yes, they are manually pushed. What we mostly need to do in this regard here is updating our release procedure to include patch release instructions as well.

@mlavacca mlavacca self-assigned this Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants