Making a release essentially consists of creating a versions file, running release-suites with this versions file as input on the server, and then announcing the release. The hard part is in making sure that the tarballs used in the versions file actually build and play nicely together, which is what the rest of this page is about.

Try to ask for some people to also do some Smoketesting.

Initial setup


Read/follow all sections if you haven't made a release before.

  • Shell account to with 'ftpadmin' group (ability to change /ftp/pub/GNOME)
  • Python 2.5 on the testing machine (to create the moduleset)
  • GIT account

  • Running ssh-agent
  • Modules should refer to, not (latter is a mirror and lags behind!)

Put the following in ~/.ssh/config (even if your username matches the one on master.go!):

Host *
        User yourusername

Setting up testing machine

mkdir -p ~/src; cd ~/src
git clone git://
git clone ssh://

Detailed steps for smoketesting and making a release

Making the gnome-2.91.94 release with the script would look something like this:

Create a module set (on testing machine)

  • Do the following:

rm -rf ~/src/tarball-gnome3/* /opt/tarball-gnome3/*  # Purge old installation
cd ~/src/releng
git pull --rebase
cd ~/src/releng/tools/smoketesting
  • Update the version number in sample-tarball.jhbuildrc / sample-tarball-stable.jhbuildrc (moduleset variable)
  • Update tarball-conversion.config if there are new download locations, module renames, or new modules
  • If this is a stable release, it is important to add limit values for actively developed modules - otherwise development releases will creep into your stable release ! The limit attribute works by specifying the too-new version. E.g. if 2.25 is the current development stream, you want to put limit="2.25" to restrict your release to picking up the latest 2.24.x tarball.
  • Run script to create versions file (the moduleset file is gnome-apps-3.0.modules for 3.0):

./ [-t <tarball download directory>] -v <gnome version> [<jhbuild moduleset file>]
  • Edit the .modules files, as necessary
    Convert-to-tarballs is slightly error-prone and ( seems to lag way behind It may also be useful to compare against

  • Copy files to

scp versions *.modules sample-tarball.jhbuildrc

Publishing the moduleset (on

If you want other people want to help build/testing it at the same time you do, follow the steps in this section.

  • Do the following:
    Note that if you update the moduleset due to bugs found while building or to include new modules, you'll need to update the version on the server too

  • Make sure cp -a does preserve the correct permissions and the files being copied are world readable.

mkdir -p /ftp/pub/GNOME/teams/releng/2.91.94
cp -a ~/*.modules ~/sample-tarball.jhbuildrc ~/versions /ftp/pub/GNOME/teams/releng/2.91.94
  • Optional: announce the jhbuild modulesets (e.g. on Planet GNOME) to get some smoketesters. Instructions for them are available at Smoketesting

Build the moduleset (on testing machine)


cp -a sample-tarball.jhbuildrc ~/.jhbuildrc.tarballs
  • If STABLE:

cp -a sample-tarball-stable.jhbuildrc ~/.jhbuildrc.tarballs
  • Real build:
    NOTE: bootstrapping Python causes problems on x86_64 and distros with Python 2.5

ssh localhost # Cleanse path from git version of gnome stuff that you have running
jhbuild -f ~/.jhbuildrc.tarballs -m bootstrap build [-s python] meta-bootstrap
jhbuild -f ~/.jhbuildrc.tarballs -m ~/src/releng/tools/smoketesting/gnome-apps-2.91.94.modules build meta-gnome-core meta-gnome-apps-tested

Note: If the build fails for some reason, you'll probably need to manually update the modulesets or re-run ./, and upload the results on See jhbuild document for how to run new session; then log in and test it for a while.

  • Some programs might need to plug on DBus system bus which isn't handled by jhbuild. To do that:

export DBUS_SYSTEM_BUS_ADDRESS="unix:path=/var/run/dbus/system_bus_socket" (or whatever path is used for system bus)
  • Push the changes

cd ~/src/releng/tools/smoketesting
mv versions .. && cd ..
git diff      # This is possibly the most IMPORTANT STEP: Make sure things look right!
git commit -a # Save the versions & sample-tarball.jhbuildrc to make it easy for next person
git push

Make the release (on

Pay close attention to all warnings/errors during 'ftpadmin release-suites'; there better be none

ftpadmin release-suites 2.91.94 ~/versions
ftpadmin simple-news 2.91.93 2.91.94

Check who provided updates and who did not (on

Use output of 'ftpadmin simple-diff' to nag those not providing updates

ftpadmin simple-diff 2.91.93 2.91.94
ftpadmin simple-diff --same 2.91.93 2.91.94

Final steps (on any machine)

Final steps, unless this is a .0 release.

  • Update Schedule for the next tarball due date

  • Send announce mail to devel-announce and (if doing a stable release) gnome-announce when everything is ready.
  • Update the corresponding Flatpak runtime in the gnome-sdk-images module. Edit the file in the branch corresponding to the release

Extra steps for .0 release

  • Create a new stable flatpak runtime
    • Branch gnome-sdk-images
    • Replace git references by tarballs in, update version in Makefile
    • Ask Alex to build it
  • Remember to mention the release name (GUADEC/GNOME.Asia host city)
  • Update the -stable files (tarball-conversion.config and versions)
  • Update the schedule scripts in the releng module to reference the new schedule files (to receive automatic mails)
  • Make sure is updated to note the new release (gnome-web-list is the contact, right?)
  • Remove the authentication on (ask a gnome-sysadmin to edit the apache config and reload the server; e.g. #sysadmin on
  • Make sure a LiveCD and VM machines are out
  • Get someone to send out the press release if there's one (tell the board when the release will happen)
  • Announce on gnome-announce-list and on devel-announce-list (and ping stro for Footnotes?)
  • Update so that it refers to the correct stable and unstable releases
    Currently sysadmin-only, ask sysadmin to edit /etc/apache2/sites-enabled/ on socket and do a service apache2 reload. The content of currently lives behind Best to talk to the website people for updating this and other website content.

  • Update links in ReleasePlanning

  • Ask bugmaster to add a new version/target milestone for the next version of GNOME in bugzilla
    GNOME target and GNOME version

  • Create jhbuild modulesets for the next development cycle
  • Make sure the new schedule is available as ics (git location: gnomeweb-wml/ and on the wiki
    The creates this, see releng module, tools/schedule directory. new still redirects to old GNOME for the ics file

Some other things we should put in a check list:

  • Have screenshots of a default GNOME (so users know what it will look like)
  • Have screencasts to demo some new features


Must-have tarballs

  • gnome-desktop includes the gnome-version.xml file that is used to display version information in various places (gnome-control-center details panel, gnome-system-monitor,...). Therefore, every release should have a gnome-desktop tarball with a matching version number.

Manual intervention likely required to avoid build/installation failures

  • the installation of the totem mozilla plugin fails. It's possible to disable the build of the plugin with this line in the .jhbuildrc file: module_autogenargs['totem'] = '--disable-mozilla'

  • Manually update the perl in the versions file

Things to check to make sure everything is right

  • Browse over to and make sure a directory with the relevant moduleset files exists. Make sure this moduleset builds (e.g. don't try regenerating the moduleset after you've already built it, unless you test the regenerated version too)

  • Browse over to{admin,bindings,desktop,devtools,mobile,platform} and spot-check, comparing to the previous release, making sure things look in order. (The simple-diff script can help here too, see the optional section above).

    • Be sure to check that the NEWS files exist and look right
    • Make certain that the perl and java bindings get installed -- this is a common error

High level overview of what the detailed steps are doing

This section is partially here for historical reasons, but partially because scripts above might hide what is being done and it may be worthwhile to keep the full list here.


  • Find out all the tarballs that are going to be in the release[1]
  • Find all the external dependency tarballs[1]
  • Build the entire set with garnome or jhbuild or whatever[1]
  • Verify that the release "works" (can log in, run programs, etc. More thorough testing of stable releases is a good idea)
  • Put the jhbuild modulesets and a sample .jhbuildrc on FTP: /ftp/pub/GNOME/teams/releng/$RELEASE/
  • run the signal-ftp-sync script.
  • Create an updated versions file (releng/tools/versions in git)[1]
  • Log into
  • Put the perl tarballs into a perl/ subdirectory of where-ever you're running from (you'll need to copy them from /home/users/tsch/gtk2-perl/<version>)

  • Run releng/tools/release_set_scripts/release-suites using the updated versions file
  • Run releng/tools/release_set_scripts/simple-news to create the relevant NEWS files
  • run the signal-ftp-sync script.
  • Announce the release to devel-announce-list and gnome-announce-list

See also

[1] releng/tools/smoketesting contains some stuff to automate finding all tarballs (in the Gnome release and external dependencies), create a jhbuild moduleset for them, and create a versions file. Read the comments at the beginning of the releng/tools/smoketesting/ script for details. That's one way to do these steps.

ReleasePlanning/MakingARelease (last edited 2017-05-12 10:14:21 by MatthiasClasen)