Too late saw this PR, so I made it on my side too... Everything looks alright, however it seems to miss few version bumps in readme & 7zVersion.h (see sub-PR NagaseIori#1 or 88e0c1b)

I thought it would be better if I just updated the files and let the maintainers handle the version bumping. Thank you for pointing that out!

@sebres - you are invited to this repository.
I would like to have sth. like this branches:

1. master - sth. like the hopefully current 7-Zip with Zstd. and so on (no push with force)
2. update - a branch, when Igor has released a new version (development area)
3. devel - a new features branch variant (development area)

What do you think?

you are invited to this repository.

Thx!

I would like to have sth. like this branches

1. agree
2. unsure I understand correctly the purposes or else the necessity of this branch... Or do you mean rather a branch that will correspond original source code of Igor only? Then sure, good idea.
3. I don't see it is really expected - some development branch can be called more informative (e. g. fix-gh-nnnn as for fix for the issues or something like rfe-some-feature for an enhancement), regardless they are placed in fork-repo or here. And if they get ready they could be a) merged to master branch and b) deleted in this repo or/and in fork.
   I never saw the necessity to have devel branch (unless one doesn't have a customer and this branch needs to represent customer test or development environment).

Yes, you are right... my first try was wrong - sth. like a special update branch makes no sence.

Most other projects use sth. like a developent branch within master ... and multiple release branches with names like 7-Zip-ZS-version-release or 7-Zip-ZS-version-staging ... maybe we should also try it this way.
Then we can create multiple smaller patches for generating 7-Zip ZS releases more easily in future.