Branching for upstream GitLab v17.3
<!--
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
-->
### 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 (`x.y`): 17.3
- As of Heptapod 17.0, the upstream GitLab minor version is also `x.y`.
- New development version (`n.w`): 17.4
### 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.
```
hg log -r "(tag('g.h.0+rc42.ce.0')~2) % heptapod"
```
Nowadays the Omnibus merges are handled by the semi-automated Upstream Merge
process.
- [x] Rails: make sure that the `heptapod-stable` and `heptapod-oldstable`
branches are fully merged in `heptapod` (make MRs if needed).
- [x] Rails, branch `heptapod`: tag the chosen branching point as
`heptapod-x.y.0a0`. Push, skipping pipeline: we do not need a tag on the
Omnibus side, and the corresponding build would be on current heads of
other GitLab components (notably Gitaly), which is inappropriate and prone
to fail is Heptapod is lagging behind.
### Release branch
- [x] HGitaly: make sure that version is greater than in stable branches,
release and check that RHGitaly was built successfully
- [x] Rails: create the `heptapod-x-y` branch, starting from the changeset
introducing the `a0` tag, by copying over and completing
`HEPTAPOD_CHANGELOG` from the previous release branch and setting
`HEPTAPOD_VERSION` to `x.y.0a1, `RHGITALY_SERVER_VERSION` and
`python/common.req`
- [x] Omnibus: create the `heptapod-x-y` branch, starting from the changeset
introducing the `a0` tag.
- [x] Omnibus: merge the `x.y.0+rc42.ce.0` upstream tag in the release branch.
This sets appropriate versions for GitLab components, notably Gitaly.
- [x] Heptapod Tests: start the `heptapod-x-y` branch
### Stable branch shift
#### Useful commands
Pull-merge in a fork of a GitLab component:
```
hg pull
hg --config command.update.check=abort update heptapod-stable && \
hg merge heptapod
```
Pull-merge in a Heptapod-only repository:
```
hg pull
hg --config command.update.check=abort update stable && hg merge default
```
#### CI Images
- [heptapod-gitaly](https://foss.heptapod.net/heptapod/ci-images/heptapod-gitaly)
+ [x] merge, commit
+ [x] push skipping CI (will be triggered by `heptapod-base`)
- [heptapod-base](https://foss.heptapod.net/heptapod/ci-images/heptapod-base/-/pipelines)
+ [x] merge, check/fix `assets/install_pythonlibs`
+ [x] commit, push
+ [ ] pipeline ok
- [hgitaly-rust](https://foss.heptapod.net/heptapod/ci-images/hgitaly-rust/-/pipelines)
+ [x] merge, commit, push
+ [x] pipeline ok
- [mercurial/hg-current](https://foss.heptapod.net/heptapod/ci-images/mercurial/-/pipelines)
+ [x] merge, check Mercurial version in the `hg_current` job
+ [x] commit, push
+ [x] pipeline ok (check resulting Mercurial version)
#### Python components
- [HGitaly](https://foss.heptapod.net/heptapod/hgitaly/-/pipelines)
+ [x] make sure the `stable` branch is merged in `default`, make a MR if
needed
+ [x] merge, commit, push skipping pipeline
#### Development, build and release tooling
- [heptapod-tests](https://foss.heptapod.net/heptapod/heptapod-tests/-/pipelines):
+ [x] merge and check the base image name in `.gitlab-ci.yml`
(it should be the target Heptapod version, e.g, `0-21-testing`).
+ [x] merge the stable branch into the release branch
- [Omnibus Heptapod]
+ [x] merge the `heptapod` branch into `heptapod-stable`, do not commit yet
+ [x] if changes in `lib/` or `files/` are non-trivial compared to
`heptapod` (`hg di -r p2()`): commit them in a
topic, start a MR to get a pipeline (it won't perform package builds).
Otherwise, just push as draft without topic.
+ [x] pipeline ok if there was one
+ [x] merge the bumped branch into the release branch (e.g.,
`heptapod-0-41`, `heptapod-1.0`, etc). The diff should be empty or
almost. Commit, push.
At this point `heptapod-stable` is the developement branch matching the
`heptapod-x-y` branch
- [x] [HDK](https://foss.heptapod.net/heptapod/heptapod-development-kit):
update the
`release-stable` or `release-oldstable` entry in `lib/gdk/config.rb`
on the `heptapod` branch (we have one single branch to rule all
series as of this writing but that can change in face of big future
structural changes).
- [Heptapod Rails]:
+ [x] merge the bumped branch into the release branch (
'heptapod-x-y'). The diff should be almost empty,
especially if the shifted branch was fully merged in the release branch.
+ [x] check that the `HEPTAPOD_SERIES` is correct in `heptapod-ci.yml` (it
is not if it was done in the same changeset as the merge of
`heptapod` into `heptapod-stable`).
+ [x] commit in a topic, open regular MR (this is enough to chase the kind of
problems that could arise)
+ [x] pipeline ok
+ [x] pull, create a tag `heptapod-x.y.0a1` *without topic*, push.
+ [x] pipeline ok. This validates that release builds will work for the
`x.y` series
- [HDK Workspaces](https://foss.heptapod.net/heptapod/hdk-workspaces):
+ [x] update the `gdk-*.yml` files for the affected series (commit/push)
+ [x] signal other developers that they must run
`./heptapod-switch-new-stable` in their workspaces.
### Opening the new development cycle
- [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.
- [x] Push skipping CI (there is indeed no tarball for `heptapod-n.w.0.pre`)
- 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 MR manually, with the ~"Upstream merge" label to
trigger the Omnibus build
- [x] Pipeline succeeds. This ensures that subsequent MRs will not be
harmed by problems introduced in the opening itself.
- [x] Rebase existing topics on the current `heptapod` branch, notably
the `upstream-merge` topic if present.
- [x] Remove the ~"Upstream merge" label on the present issue: there is no reason to block the process any more.
- [x] Solve existing ~"Upstream merge" issues.
[Heptapod Rails]: https://foss.heptapod.net/heptapod/heptapod/-/pipelines
[Omnibus Heptapod]: https://foss.heptapod.net/heptapod/omnibus-heptapod/-/pipelines
issue