Development / Maintenance / Release workflow

[pinkforest]

I would recommend merging (no squash - to keep the history intact) from release/4.0 into main and keep the main as development branch for the next release what ever it will be in CHANGELOG.md in the branch.

This would greatly simplify the contributions and workflows overall leading to less errors.

This would align with the majority of the other projects contributors are used to.

Development workflow

I also would not use in-origin-repo branches and all the development should happen in fork(s) from where the PR's originate which will be consistent between maintainers and contributors.

All rendered contexes should be via remote fork feature branches also for the consistnecy.

This would also simplify the contributions and maitenance workflow and make it consistent and allows clean origin branches.

Also GitHub makes it hard to sync fork when there is a new branch in origin.

This all given if:

• develop branch is redundant
• release/x.y branches should be presented as release/x.y.z instead that get pushed into tag(s) and release
• release/x.y.z should be immutable on which release action can create the given branch
• backported fixes (non-breaking) should get release/x.y.z via release action automatically
• main branch can contain all the changes regardless of the release

[rozbb]

I think that'd work nicely. Just to make sure I understand:

• main is where all development happens
• There will be release/x.y branches off of main. These will be where backports happen, if necessary.
• Each release/x.y branch will have tags marked release/x.y.z

Is that right?

[pinkforest]

Yup, no need for backports branches and all the tags can be from main to make it consistent.

backports branches can be instead done ad-hoc as needed - this simplifies not needing to maintain separate branches.