Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 183
    • Issues 183
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • heptapod
  • heptapodheptapod
  • Issues
  • #127
Closed
Open
Created Nov 25, 2019 by Georges Racinet@gracinet🦑Owner

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:

  1. there's a risk of a successful merge that could turn out to be inconsistent
  2. 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

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking