I've added a release-0.41 maintenance branch from the 0.41.0-rc1 tag. Additionnaly, I merged all 0.41.0-rc2 to -rc8 tag into the release-0.41 branch using --no-ff (no fast-forward) so that one could add a specific RC maintenance branch from the RC merges (which are thus identified by specific commit messages)
I've created a (still local) release-0.41.0-rc7 branch to work on issues I've submitted.
A standard and safe workflow should be, for example, such as:
new features development on the develop branch (which is called qtfork in FPDB repository)
release maintenance should be done on the release-M.m branch
when a 0.41.0-RC is planned: merge the development branch into the release-0.41 branch and fix RC issues in the release branch. When RC is ready and released, add an 0.41.0-rc9 tag in the release branch and merge it back into the development branch
when a new 0.42 release is planned:
-- add a 0.42 versionning the tag on the development branch
-- create a new release-0.42 branch from the versionning tag
-- make fixups and prepare RC, add release tag and merge back into develop
With that workflow any release could be maintained easilly with a little extra cost of managing the release branches and tag.
Hello,
I've added a release-0.41 maintenance branch from the 0.41.0-rc1 tag. Additionnaly, I merged all 0.41.0-rc2 to -rc8 tag into the release-0.41 branch using --no-ff (no fast-forward) so that one could add a specific RC maintenance branch from the RC merges (which are thus identified by specific commit messages)
I've created a (still local) release-0.41.0-rc7 branch to work on issues I've submitted.
A standard and safe workflow should be, for example, such as:
With that workflow any release could be maintained easilly with a little extra cost of managing the release branches and tag.