Shunkichi Sato

- retitled to align with the original requirements described in #1594 - changed implementation policy as described in https://github.com/hyperledger/iroha/pull/4668#issuecomment-2165073957

- blocked by #4373 may become obsolete after #4373 as signatories are planned to be immutable so far

My basic idea keeps coming back to the multi-signature section of https://github.com/hyperledger/iroha/issues/2085#issuecomment-1980557101

What if we do the following: - stop tracking any executor blobs - make the executor path an environment variable - introduce a hook to build with iroha binary for...

I agree @mversic , there would be no good reason to pull the last published dev image and test it in the release workflow. I also think a test by...

My experience in #4411 led me to think about modularity of not only executor but also genesis and swarm, and about consistency between them. The following is a suggested flow...

@BAStos525 I mean [the corresponding step of the release workflow](https://github.com/hyperledger/iroha/blob/bf789efa4c114db422c701737218f6c4202be759/.github/workflows/iroha2-release.yml#L48-L51) would ignore `iroha:TAG` built in local and pull `iroha:dev` hardcoded in `docker-compose.yml`

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

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...

> 5. 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`