There are several steps involved in managing and making a release of MAAS. This is an attempt to document what is currently done, and is not intended to be prescriptive of how it should work.
How to release MAAS
-
when releasing for the first time for a major release, create the appropriate repositories
a. create a PPA on https://launchpad.net/~maas.
b. copy any needed additional dependency from PPA of the previous major release to the new PPA.
c. request a new track on the Snap store formaas
snap
d. request a new track on the Snap store formaas-test-db
snap
e. Make sure themaas-test-db
snap uses the same base as themaas
snap, and uses the latest Postgres version for that base. -
Make sure the system tests pass for the revision that you’re planning on releasing, both the normal and
-ea
variant. -
run the
maas-tag-release
jenkins job to update MAAS version and tag a release,Important: The version should use the format <MAJOR>.<MINOR>.<MICRO>(a|b|rc<num>) for example
2.9.0b1 -
in the maas source tree, update to the release tag and build packages
git remote update git checkout $release_tag if echo $release_tag | grep -q "^2\.[0-3]"; then ubuntu_release="xenial" elif echo $release_tag | grep -q "^2\.[4-8]"; then ubuntu_release="bionic" elif echo $release_tag | grep -q "^2\.[9]"; then ubuntu_release="focal" fi utilities/release-build $ubuntu_release
Important: make sure that
DEBFULLNAME
andDEBEMAIL
variables are set to the right values for the debian package. -
upload packages built from the previous step to the PPA
This can be done using the following script:utilities/release-upload <PPA> <changes file>
which performs checks to ensure that the version being uploaded matches the target PPA (in terms of major version and release stablity.
-
when uploading a stable release (whether a final or a point release), a stable
ppa:maas/2.X
PPA should be usedutilities/release-upload ppa:maas/2.X build_pkg/maas_2.X.*.changes`
The stable PPA can be used also to for preleases of a
2.X.0
release since there’s no stable release for that major at this point -
when uploading a pre-release for a point release (e.g.
2.X.1-rc1
), a testingppa:maas/2.X-next
PPA should be usedutilities/release-upload ppa:maas/2.X-next build_pkg/maas_2.X.*.changes`
-
-
Wait for Launchpad to build and release to PPA.
-
Wait for snaps to be built, release them to the right risk channel.
-
Create a new (active) milestone for the release after this one, to target bugs that weren’t completed for this release.
-
Mark closed bugs as released with
lprelease.py
tool fromlp:juju-release-tools
(with this patch applied)python3 lprelease.py maas $milestone -m $next_milestone
Also, create a release for the milestone on LP.
-
On final releases
- post release notes/announcements in Discourse
- switch default snap track to the new release
-
When starting a new major release, update or push the
maas-test-db
snap to the new track.
Releasing RC1
Once an RC1 has been released a branch should be created for the release. Branching will also require build scripts to be updated to use the new branch.
- Open up git to branching on Launchpad - lp:maas is locked down to prevent accidental commits. To branch you’ll need to allow yourself to force push. You can do this on the LP:MAAS launchpad permissions page. Ask MAAS Engineering Manager to add you to the second rule for the appropriate pattern (e.g.
2.*
or3.*
) and allow force pushes. - Create and push the branch e.g.
git pull
git checkout --recurse-submodules 2.9.0-rc1
git checkout -b 2.9
git push --set-upstream origin 2.9
- Ask the design team to branch maas-ui
- Ask @billwear to branch lp:maas-offline-docs
- Point the maas-ui and lp:maas-offline-docs git submodules in lp:maas to the branch
e.g.
cd maas/src/maas-offline-docs/src
git pull
git checkout 2.9
maas/src/maasui/src
git pull
git checkout 2.9
- Commit the changes
git commit src/maas-offline-docs/src src/maasui/src -m "Switch docs and UI to 2.9 branch"
- change the
MAAS_PPA
value inMakefile
to the release PPA (e.g.ppa:maas/2.9
) - Set the Source: for the Snap builds to the branch you just created when building the Snap with Launchpad.
- Release snap builds to
candidate
channel (and closebeta
).
Releasing final
On final releases of a new major, some extra steps are required:
- Release snap builds to the
stable
channel (and closecandidate
). - Release
maas-test-db
to thestable
channel (and closecandidate
). - Switch default tracks for both
maas
andmaas-test-db
to the new version.
Troubleshooting
If a Snap fails to build due to a proxy error you can use the LaunchPad API to request a rebuild.
- Start the LaunchPad shell with
lp-shell production devel
- To rebuild arm64 and ppc64el you would do:
snap = lp.load('/~maas-committers/+snap/maas-2.9')
for arch in ('arm64', 'ppc64el'):
snap.requestBuild(archive=snap.auto_build_archive, distro_arch_series='/ubuntu/focal/%s' % arch, pocket=snap.auto_build_pocket, channels={"snapcraft": "stable"})