Releasing Geary

These are the steps that should be taken when cutting a new Geary release.

If you are new to releasing GNOME software, you'll need an account on both and It's also worth reading through the Maintainer's Corner and in particular, Making a Release.

Note that Geary currently uses pre-release version incrementing.

Check it builds

Stable, point releases should be checked against the current stable branch, while new versions can be checked against master.

  1. Check the minimum versions of software dependencies listed in INSTALL and debian/control matches the versions specified in src/CMakeLists.txt.

  2. Ensure it builds on with the minimum supported versions of GTK+, Vala, WebKitGTK, etc. The easiest way to do this is install the oldest targeted distro in a VM using Boxes or similar, and compile and test it there.

  3. Ensure the Ubuntu package config in the source tree builds against the minimum targeted version of Ubuntu. Again, the easiest way to do this is to install it in a VM and build it there.


  1. Run through the testing checklist, preferably also on oldest targeted LTS release.

  2. Browse through the list of bugs targeted for this release, test to ensure they are fixed.
  3. Check Geary still works fine with all supported providers, and against a generic IMAP server.

Making the release

  1. Check out the branch to be released locally
  2. Do both a git pull and git status to check for remote and local changes

  3. Update the version number in CMakeLists.txt

  4. Update NEWS:

    1. Add a new section for the release with the new version number and today's date
    2. Get a list of changes using git log --oneline LASTREL.., where LASTREL is the tag of the last release on the current branch

    3. Summarise new features if any (most important first), then bugs fixed if any (most important first). Smaller changes and code cleanup can be noted, but shouldn't be listed. This file is read by non-hackers, so keep it non-technical.
    4. Include b.g.o. bug numbers if there is one
    5. Include patch author names if they aren't listed in THANKS

    6. Ensure all b.g.o. bugs that were targeted for this release and have been marked as fixed have the included
    7. Include a list of UI and User Guide translation languages updated, and the name of the people that contributed the translations
  5. Update debian/changelog using a brief version of the NEWS file. In emacs:

    1. M-x debian-changelog-add-version

    2. Update version number and distribution
    3. Copy, paste and trim NEWS
    4. M-x debian-changelog-finalise-and-save

  6. Update THANKS with the details of people who contributed patches

  7. Do one last git pull, then commit the changes above and do a git push

  8. Tag the release: git tag -a geary-VER, where VER is the version number

  9. Push the tag to the repo: git push origin geary-VER

  10. Generate a xz-compressed tarball, you can use git archive, but the easiest way to do that is to download new tag as a .tar.gz from the git web interface

  11. Upload to and install it

Post-release builds

  1. Flatpak:
    1. Update the tarball name and SHA256 hash in org.gnome.Geary.json of the stable branch of the gnome-apps-nightly repo

    2. Keep an eye on on the builds starting and completing successfully on #flatpak-builds on Freenode
  2. Geary Team PPA:

    2. Upload builds to the Geary Release PPA by running from directory containing Geary source tree

    3. Check your email that they were uploaded okay
    4. Keep an eye on the builds completing successfully

Let people know

Once the builds have successfully completed, update the wiki and send an email!

  1. Fire up the new release
  2. Compose a release email with a short summary, and the contents of NEWS
  3. Address it to and

  4. Set the reply-to address as

  5. Hit Send

Sit back, relax, and bask in the radiance of the latest Geary version making people's email lives a bit better.

Apps/Geary/ReleaseProcess (last edited 2016-12-25 04:07:49 by MichaelGratton)