We've recently agreed to use a branch based development as opposed to trunk based, see 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
I would like to strongly recommend the oneflow model, as described here: 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:
Highlights from the article:
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.
Well the article explicitly mentions the problem we were discussing:
First, when the above condition ("every new production release is based on the previous one") is not satisfied. As an example, take the Python programming language. It has two incompatible versions, 2 and 3. Both of them receive bugfixes and security patches - however, that doesn't mean a new release of Python 3 is based on the commit of the latest release of Python 2. The two versions have diverged, and while they surely share a lot of code, you can't say that one is based on the other (talking from a purely version control perspective).
That is what we like to do though, if not for the upcoming 0.19.2 vs 0.20 split, then later for the v1 vs v2 split, so we might as well figure out how to do it now.
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
The variety of OneFlow being proposed here, if I understand correctly, is the one with two long-lived branches (master and develop, let's call it OneFlow+) and is actually very similar to GitFlow, the differences AFAIU being not in the branch setup, but:
So it's basically "keep the history clear" and "leave people some freedom". The latter could make OneFlow+ less of an obstacle for code base splits, but IMHO neither GitFlow nor OneFlow+ actively help with that: both seem to only support "one release builds on the previous one" out of the box.
@araq
That is what we like to do though, if not for the upcoming 0.19.2 vs 0.20 split, then later for the v1 vs v2 split, so we might as well figure out how to do it now.
IIRC the article mentions how to adapt the model to handle that case (eg for python2 vs python3, or in our case nim1 vs nim2): "every new production release is based on the previous one" holds true for each of nim1 and nim2, so we'd adapt the model by having 2 long-lived development branches (1 for nim1, 1 for nim2) instead of just 1.
But the same release+patch strategy still applies: each release(or patch) is short-lived and merged back to its long-lived development branch as soon as it's tagged.
correct; it's simpler than traditional gitflow because in gitflow we must know in advance where a bugfix PR goes (is it v1? is it v2? is it 0.18.x branch? is it 0.17.x release? ) which is often not practical (especially when PR contains multiple commits, only one of which has the bugfix)
with oneflow, you worry about it later when you realize "would be nice to backport this bugfix all the way back to 0.17.x release.
well that's the point of creating a (short-lived) branch per release/hotfix before applying a new tag (eg 0.19.3): we apply a number of cherry-picked bugfixes to release/0.19.3 branch (maybe with additional manual commits to adjust if needed) until we're satisfied with CI, and then we finally tag 0.19.3 and merge release/0.19.3 : end of life for that branch.