iroha icon indicating copy to clipboard operation
iroha copied to clipboard
verified publisher icon hyperledger

backporting workflow

Open s8sato opened this issue 1 year ago • 2 comments

image https://blogs.oracle.com/linux/post/backporting-patches-using-git

Regarding backports, my suggestion is to first make commits on the main branch and then apply them to every release branch as needed.

fixes should land on master first, be tested there, and only then be back-ported to older releases. https://stackoverflow.com/a/13275789

There are some actions that would help this approach:

  • https://github.com/marketplace/actions/backporting
  • https://github.com/marketplace/actions/backport-action

might be an example:

  • https://github.com/kata-containers/community/blob/main/Backport-Guide.md

s8sato avatar May 08 '24 10:05 s8sato

ok, what you suggest this seems better:

  1. make a fix commit to the main branch
  2. cherry-pick the commit to the release branch (forked of at the time of making the 1st tag)

This solves the issue with the CHANGELOG.md. The issue that remains is the CI. We need CI to run on every PR to release branch. I'm not sure how to do that best. Maybe we can have CI workflows that target all branches starting with a prefix, like 2.0.0 (currently we have a branch 2.0.0-pre-rc.21). Or we should remain with stable branch for the latest public release

mversic avatar May 16 '24 10:05 mversic

What do you think about having stable/2.0.0 etc. and filtering by stable/ ? However, in that case, the current stable would not coexist with them due to branch name restrictions

s8sato avatar May 17 '24 09:05 s8sato

This is the description of Iroha's workflow:

  1. We have main branch which everyone works on and merges their PRs to
  2. We create new branch from main when we publish a new major version
  3. We create git tag and publish to crates.io from this new branch

Example

New major release

Let's say we are releasing 2.0.0-rc.2.0 (previous release was ):

  1. Create a new entry in CHANGELOG.md (cut it from the Unreleased section if possible)
  2. Create a branch called 2.0.0-rc.2(notice the absence of the minor version) from the main branch
  3. In the version branch create a tag v2.0.0-rc.2.0 (tags are prefixed with v to make our life in CI easier)
  4. Publish new 2.0.0-rc.2.0 release of all Iroha crates to crates.io from the version branch
  5. In the main branch update version of Iroha in Cargo.toml files to 2.0.0-rc.3.0 (next release)

New patch release

Making a bug fix for 2.0.0-rc.1 (notice the version is 1 behind latest release):

  1. Commit the fix to the main branch first
  2. Update CHANGELOG in a separate commit (we must have an entry for patch versions in the main branch as well)
  3. Cherry-pick commits (all bugfix and CHANGELOG) from main into the version branch (in this case 2.0.0-rc.1)
  4. In the version branch update version of Iroha in Cargo.toml files to 2.0.0-rc.1.1
  5. In the version branch create a new tag v2.0.0-rc.1.1
  6. Publish new release of all Iroha crates to crates.io from the version branch

mversic avatar Oct 10 '24 14:10 mversic

About the patch release section, I'd like to disambiguate whether the separate commits should be on my fork or on the target branches. I guess a single commit on the target branches that are squashed from the separate commits on my fork would be enough:

  1. Commit the fix to the main branch first
  2. Update CHANGELOG in a separate commit (we must have an entry for patch versions in the main branch as well)
  3. Cherry-pick commits (all bugfix and CHANGELOG) from main into the version branch (in this case 2.0.0-rc.1)
  4. In the version branch update version of Iroha in Cargo.toml files to 2.0.0-rc.1.1

In this case, for example,

  • The main branch should have a commit from a PR fix: my patch (#0000) that consists of fix: my patch and chore: update CHANGELOG.md
  • The 2.0.0-rc.1 branch should have a commit from a PR fix(BACKPORT): my patch (#0001) that consists of fix: my patch and chore: update CHANGELOG.md, where the latter should be amended to increment the minor version to 2.0.0-rc.1.1

Am I correctly understanding @mversic ?

s8sato avatar Jan 29 '25 12:01 s8sato

yes except:

where the latter should be amended to increment the minor version to 2.0.0-rc.1.1

shouldn't be amended but added as a new commit

mversic avatar Jan 29 '25 12:01 mversic

  1. In the version branch create a new tag v2.0.0-rc.1.1

git checkout 2.0.0-rc.1, git tag v2.0.0-rc.1.1, and directly git push upstream v2.0.0-rc.1.1 ?

EDIT: added git tag v2.0.0-rc.1.1

s8sato avatar Jan 29 '25 13:01 s8sato

you must push a tag: git push upstream tag v2.0.0-rc.1.x

mversic avatar Jan 29 '25 13:01 mversic