Better branching strategy for the Heptapod project itself
Up to now, we've based our developments on a GitLab CE stable release, and for upstream version changes, we merged from the upstream support branch, with help of a conflict resolution script.
There are several drawbacks to this approach:
- there's a risk of a successful merge that could turn out to be inconsistent
- we still have too much manual conflict resolution to make.
It would be better to base the main heptapod
branch onto an upstream commit that used to be master
, create a release when developments are nearing completion, and only in that branch, merge the upstream stable branch.
Here's an example of how it could work for Heptapod 0.8 and Heptapod 0.9, assuming this goes from GitLab 10.4.7 to 10.5.8
graph TD;
gl4rc["gitlab@10.4.0-rc2"] --> gl5rc["gitlab@10.5.0-rc1"];
gl5rc --> glmaster["gitlab@master"];
gl4rc --> gl47["gitlab@10.4.7"];
gl5rc --> gl58["gitlab@10.5.8"];
gl4rc --> 8pre["heptapod@0.8-pre"];
8pre --> 8rc1["heptapod-0-8@rc1"];
8rc1 --> 80["heptapod-0-8@0.8.0"];
80 --> 81["heptapod-0-8@0.8.1"];
gl47 --> 80;
and then, the 0.9 development / release cycle could look like this:
graph TD;
gl4rc["gitlab@10.4.0-rc2"] --> gl5rc["gitlab@10.5.0-rc1"];
gl5rc --> glmaster["gitlab@master"];
gl5rc --> gl58["gitlab@10.5.8"];
gl4rc --> 8pre["heptapod@0.8-pre"];
8pre--> 9pre["heptapod@0-9-pre"];
gl5rc --> 9pre;
9pre --> 9rc1["heptapod-0-9@rc1"];
9rc1 --> 90["heptapod-0.9@0.9.0"];
gl58 --> 90;
8pre --> 8rc1["heptapod-0-8@rc1"];
It's quite possible that this forces us to make a new minor version for each new minor GitLab version, but that isn't really a bad thing, we'll have to do it at some point anyway