Prepare Heptapod 1.4 hypothetical branching
<!-- This task list fulfills two related goals: - branching out for a new release - allowing development and upstream merges to proceed in the default series It refers to other task lists, hence sub issues to be created and treated. The outcomes are - the release branches (e.g, heptapod-0-41) where needed, ready to accept merges of upstream patch releases (e.g., v16.3.6) - the `heptapod-stable` branches are the development branches for the release branches, ready for minor developements and bugfixes. - two alpha tags: `a0` (e.g., heptapod-0.41.0a0) at the branching point on a development branch and `a1` after the branching, on the release branch. - the `heptapod` branches are ready for development of the next version and related upstream merges. - CI/CD back to normal operation --> The upstream merge process having [reached the GitLab 16.10 branching point](!720), we need to prepare a branching point for a possible future Heptapod release, but chances are that we will skip it, hence we will not perform all the standard tasks of the new cycle procedure (hopefully this will be the last time we skip an upstream minor version). ### Information <!-- Please enter the relevant version numbers. The "new release version" takes the `x.y` form, and matches the release branch created in this task list (`heptapod-x-y`). the new development version is the provisional next one. It can be changed at the end of the development cycle for various reasons. --> - New release version (`1.4`): - Upstream GitLab minor version (`16.10`): - New development version (`1.5`): ### Preliminary for new development cycle - [x] Perform the oldstable branches shift - [x] Make sure that HGitaly protocol files in `default` branch are up to date with Gitaly `g.h` and that heptapod/ci-images/heptapod-gitaly> uses Gitaly `g.h` in its `default` branch. ### Branching point - [x] Omnibus: make sure that the first commit of the upstream release branch for `g.h` is merged in the `heptapod` branch and builds: ``` hg merge "tag('g.h.0+rc42.ce.0')~1" ``` (we do not use the true branching point (`~2`) because all the GitLab component versions are set to development branches, hence not relevant in catchup times. To be revisited when we have at most a few days of lag). - [x] Rails, branch `heptapod`: tag the chosen branching point as `heptapod-x.y.0a0`. Push. - [x] wait for Omnibus and Heptapod Tests pipelines to confirm. ### Release branch Skipped. ### Opening the new development cycle - Stable branches shift: skipped - [x] Heptapod Tests, branch default: change the base image to `n-w-testing` - Omnibus, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `n.w.0.pre` - [x] CI/CD: change cache key in `heptapod-ci.yml` - [x] Tag as `heptapod-n.w.0.pre-1`. Caution: do not forget the `-1` suffix. - Pipeline skipped in tag push above. - Rails, branch `heptapod`: - [x] change `HEPTAPOD_VERSION` to `heptapod.n.w.0.pre` - [x] CI/CD change cache key in `heptapod-ci-yml` - [x] Commit, push, open regular MR. - [x] Pipeline succeeds. This ensures that subsequent MRs will not be polluted by problems introduced in this opening. - [x] Rebase existing topics on the current `heptapod` branch, notably the `upstream-merge` topic if present. - [x] Resume upstream conversion (e.g., solve existing ~"Upstream merge" issues). ### Wrapping it up Skipped (tag on the release branch)
issue