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