/cc @araq @kaushalmodi| ---|--- We've recently agreed to use a branch based development as opposed to trunk based, see [https://github.com/nim-lang/Nim/issues/7527](https://github.com/nim-lang/Nim/issues/7527) ([RFC] Nim development and release model - 1.0 and beyond #7527) and are now figuring out a good branching/release strategy, see recent discussion on gitter: [https://gitter.im/nim-lang/Nim?at=5bd9f9615760a73eb419a490](https://gitter.im/nim-lang/Nim?at=5bd9f9615760a73eb419a490)
I would like to strongly recommend the oneflow model, as described here: [https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) which I strongly recommend to read before commenting here. This model is much simpler than the traditional gitflow model and is better suited for github ecosystem based on PR's since there's a single long-lived development branch (our current devel branch, so let's call it devel below) Pros: * pretty close to what we already do * development on devel is never stopped (no need to "freeze for 1 week") * single long lived development branch (less confusion) [1] * PR's target devel (no need to argue what branch should a PR target, as is case with gitflow which splits bw bugfixes vs new features) * allows tagged releases x.y.z (eg release/0.20.0) and hotfixes (eg hotfix/0.20.1) to released versions * release branches and hotfixes (eg release/0.20.1) are **short-lived** and merged to devel as soon as their tip gets a tag (and that tag is known from the branch name, ie 0.20.1) Highlights from the article: * normal development (bugfixes and new features) happens targets devel * (this is different from what we do) a (short-lived) release branch (eg release/0.20.0) is started off from devel (not necessarily its tip but a point in history that makes sense to branch the release off from, eg `git checkout -b release/2.3.0 9efc5d` ; it's tested and can get additional bug fixes/regressions (either cherry-picked from devel or directly; it's not super important as it's short-lived), until it's satisfactory, at which point it gets a tag and is merged to devel. End of life for that branch. * hotfixes are similar, see article. # footnotes * [1] a separate long-lived "master" branch is used in addition to "devel" branch (see "Variation - develop + master" in the oneflow article), "whose only purpose is to point to the last released commit. Each time the version number is bumped, the 'latest' branch is fast-forwarded to the newly created tag." IIRC that's pretty much what we already do; development never occurs there (and no PR target it), hence the "oneflow" name is still valid as there's still a single long-lived branch where development occurs.
