Yes, I believe so! I'll send the official email shortly to kick off the
process.
--
For posterity: I was working with Ádám Sághy on the release branch
strategy. Note: develop contains future feature work not fit for release.
That can be worked out by committing a patch to disable/remove the future
feature work (let's call it "RFIX"). We only want RFIX changes on the
release branch, but since part of the process necessarily includes merging
release/1.13.0 back into develop
<https://fineract.apache.org/docs/current/#_step_13_close_release_branch>,
RFIX would be applied to develop. The solution I came up with is to simply
revert RFIX after release/1.13.0 is merged back into develop.
Also note: A couple bugfixes need to be cherry-picked into release/1.13.0.
git should handle this fine--when we later merge release/1.13.0 into develop it
will detect if a cherry-pick has already been applied and not re-apply it.
I recall git will also/even gracefully handle merges from develop →
release/1.13.0 if we decide to do that, but we can also just rebase and
force-push release/1.13.0 (but only while we're working on the release and
before we tag for 1.13.0).
To illustrate the first note, please see attached. Explanation:
- A is a commit on develop before the branch point
- B is another commit on develop (a child of A) and the branch point for
release/1.13.0
- RFIX is as described above -- it removes/disables the future feature
work we don't want to release
- C is continued parallel work on develop, a child of B
- D is a cherry-picked bugfix, the last commit to release/1.13.0, and
the commit we'll actually build & release, hence, tagged 1.13.0
- revert RVIX is where we undo the patch that must only be part of the
release
- E is continued work on develop, post-release and post-merge of
release/1.13.0
Some notes:
- following this strategy, git describe will work as intended
- I think it's valid if some nodes in this graph represent multiple
commits
- this release branching strategy is separate from the maintenance
release process
<https://fineract.apache.org/docs/current/#_maintenance_release_process>,
should we need/want to create 1.13.1, 1.13.2, 1.13.3, ...
- I made the graph using mermaid gitgraph
<https://mermaid.js.org/syntax/gitgraph.html>. I created/rendered it
using both the Nextcloud Text editor and the mermaid live editor
<https://mermaid.live>. The PNG and SVG are rendered bitmap and vector
representations (respectively) and the .md file is the mermaid source
wrapped in a fenced code block for easy copy/paste into a capable
markdown+mermaid editor or rendering engine.
```mermaid
---
config:
gitGraph:
mainBranchName: develop
---
gitGraph
commit id: 'A'
commit id: 'B'
branch release/1.13.0
commit id: 'RFIX'
checkout develop
commit id: 'C'
checkout release/1.13.0
commit id: 'D' tag: '1.13.0'
checkout develop
merge 'release/1.13.0'
commit id: 'revert RFIX'
commit id: 'E'
```
