Release Management

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

  1. when releasing for the first time for a major release, create the appropriate repositories

    a. create a PPA on
    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 for maas snap
    d. request a new track on the Snap store for maas-test-db snap
    e. Make sure the maas-test-db snap uses the same base as the maas snap, and uses the latest Postgres version for that base.

  2. Make sure the system tests pass for the revision that you’re planning on releasing, both the normal and -ea variant.

  3. 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

  4. 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
    elif echo $release_tag | grep -q "^2\.[4-8]"; then
    elif echo $release_tag | grep -q "^2\.[9]"; then
    utilities/release-build $ubuntu_release

    Important: make sure that DEBFULLNAME and DEBEMAIL variables are set to the right values for the debian package.

  5. 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 used

      utilities/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 testing ppa:maas/2.X-next PPA should be used

      utilities/release-upload ppa:maas/2.X-next build_pkg/maas_2.X.*.changes`
  6. Wait for Launchpad to build and release to PPA.

  7. Wait for snaps to be built, release them to the right risk channel.

  8. Create a new (active) milestone for the release after this one, to target bugs that weren’t completed for this release.

  9. Mark closed bugs as released with tool from lp:juju-release-tools (with this patch applied)

    python3 maas $milestone -m $next_milestone

    Also, create a release for the milestone on LP.

  10. On final releases

    • post release notes/announcements in Discourse
    • switch default snap track to the new release
  11. 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.

  1. 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.* or 3.*) and allow force pushes.
  2. 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
  1. Ask the design team to branch maas-ui
  2. Ask @billwear to branch lp:maas-offline-docs
  3. Point the maas-ui and lp:maas-offline-docs git submodules in lp:maas to the branch


cd maas/src/maas-offline-docs/src
git pull
git checkout 2.9
git pull
git checkout 2.9
  1. Commit the changes git commit src/maas-offline-docs/src src/maasui/src -m "Switch docs and UI to 2.9 branch"
  2. change the MAAS_PPA value in Makefile to the release PPA (e.g. ppa:maas/2.9)
  3. Set the Source: for the Snap builds to the branch you just created when building the Snap with Launchpad.
  4. Release snap builds to candidate channel (and close beta).

Releasing final

On final releases of a new major, some extra steps are required:

  1. Release snap builds to the stable channel (and close candidate).
  2. Release maas-test-db to the stable channel (and close candidate).
  3. Switch default tracks for both maas and maas-test-db to the new version.


If a Snap fails to build due to a proxy error you can use the LaunchPad API to request a rebuild.

  1. Start the LaunchPad shell with lp-shell production devel
  2. 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"})