search

hyperledger / iroha

Iroha - A simple, enterprise-grade decentralized ledger
https://wiki.hyperledger.org/display/iroha
Apache License 2.0
415 stars 275 forks source link

backporting workflow #4570

Open s8sato opened 3 weeks ago

s8sato commented 3 weeks ago

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:

might be an example:

mversic commented 2 weeks ago

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

s8sato commented 2 weeks ago

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