I wanted to discuss our plan wrt Mir releases, now that we’ve moved to GitHub and have more control of our CI system.
NB: this is work in progress, so expect changes.
I’d like our release process to be non-intrusive and automated as much as possible.
There’s a handful of things that need to be available after a Mir release:
Nice to haves
Some additional things that we could do:
- Fedora packages in the Mir COPR and/or Fedora archives
We’re hosting our code on GitHub now, and using Travis for CI. Ideally, a release tagged on master would result in all the artefacts mentioned above being available automatically after a while.
Our master branch should see all the incoming code, and should receive the releases merged back when done. A release in process should not prevent code landing on the master branch.
So I propose a the process as follows:
- we branch a release candidate into
git checkout -b release/0.29 master
1.1. Update the version [CMakeLists.txt]
1.2. Update the changelog [debian/changelog]
- we push to MirServer/mir and create a Pull Request for the release branch
git push --set-upstream origin release/0.29
- CI picks this up and does everything in its power to prepare and test staging artefacts (Mir Team RC PPA, snap store candidate channel)
- we cherry-pick fixes from
master, or commit directly to
- see 2.
- when happy (see: the test plan), we tag the version and push
git commit --message "0.29 Release"
git tag --sign v0.29.0 release/0.29
git push origin v0.29.0
- see 2
- when the Pull Request is approved, see 2., but this time things are published to the stable channel and copied to the release PPA, and to Ubuntu as well.
I’d like to use Launchpad infrastructure as much as possible for Ubuntu packages and snaps, see  however.
 It takes longer for a PPA to build across all architectures than Travis allows us to run jobs for. This means that we might need to split build and autotest/publish steps between the CI and merge stages. So extensive testing and publication to stable would actually happen on merging of the
release/0.29 branch to
master. That follows, however, what we plan to do with non-release merges into master, so maybe that’s fine?
If there’s anything I’m missing, please reply!
git config --global push.followTags true will make
--follow-tags the default.