Making A Release

If you are making a release for someone else, you'll need to know whether the module is using pre-release version incrementing (i.e. bumping the version number just before release) or post-release version incrementing (which is preferred). Most everybody used to bump the version number just before the release but we've found that bumping just after the release works better because people can explicitly require the version number in HEAD; i.e. if the last release of gtk+ was 2.5.1 and new API is added, its nice for any module that uses that API to immediately require gtk+ 2.5.2. You can tell which method a module is using by whether the version number in or matches the version number of the last release of the module.

  • Make sure you're up to date:
    • git pull

  • Make sure you don't have local changes and/or revisions:
    • git status

  • If you have been using pre-release incrementing, increment the version number in your For instance, increase the version argument in the AM_INIT_AUTOMAKE macro.

  • If you have a comment in some file (e.g. README) about whether the given version is stable or unstable, and you are switching from stable to unstable or vice-versa with this release, be sure to update the comment.
  • For libraries, update the LT_VERSION string. There's usually a comment in that explains how this works. For instance:
    • # Before making a release, the LT_VERSION string should be modified.
      # The string is of the form C:R:A.
      # - If interfaces have been changed or added, but binary compatibility has
      #   been preserved, change to C+1:0:A+1
      # - If binary compatibility has been broken (eg removed or changed interfaces)
      #   change to C+1:0:0
      # - If the interface is the same as the previous version, change to C:R+1:A
  • For the gnome-desktop module only, update the overall GNOME version. For instance, here I am doing a release for GNOME 2.3.1 on March 14.
      GNOME_DATE="March 14, 2003"
  • Update the version number at the top of the README file.
  • Add an entry to the NEWS file. You should read through the Git commit log and come up with a bullet point for each significant change and credit the person(s) who did the work. Some tips:
    • If several entries relate to the same change only use a single bullet point.
    • Try to make the bullet points short and snappy but understandable for a general user. That's not always easy.
    • Do not forget to include updated dependencies, since it makes life easier for packagers.
    • Generate the list of translations from all the commits under the po directory. Note that the actual translator isn't always the one with who pushed the commit -- try to credit the correct person/team. The format is $locale ($translator). Sort alphabetically by locale. You might use a format similar to the following (note that you can use one line per language for translations):

      • =============
        Version 2.3.1
                * Blah blah blah
                * az (Metin Amiroff), be (Dmitry G. Mastrukov), bg (Alexander Shopov),
                  da (Ole Laursen), eo (Joël Brich), es (Pablo Gonzalo del Campo),
                  .... and zh_TW (Abel Cheung).

      The translations section is the most time-consuming part. This script or this one might assist you.

  • Do an ./ && make && make install && make distcheck. Fix any issues that crop up. Distcheck errors can be particuarly difficult, but releasing often makes it easier to discover and fix these problems. Some tips:

    • If a file comes up not found during distcheck, check that the file in question has been added to the in the component it comes from -- this can be the case if the files are referenced by po/ but someone forgot to add that file to the
    • Don't forget to unset environment variables like LINGUAS that influence tarball generation (translations in this case)
  • Distcheck finishes. It should show you something like this:
    • ==================================================
      gnome-panel-2.3.1.tar.gz is ready for distribution
  • Do a git commit.

  • Do a git push. If that fails because someone has pushed since you last updated, then you'll need to repeat the entire process. Well, update, add a new NEWS entry, and make distcheck again.

  • Tag the release; This will allow you to make a branch later if you so desire but for now, at least it make it easy to see what was included in a particular release. The commit message for the tag will be included in a changes file in the release directory.
    • $ git tag -a 2.3.1 (from whatever branch you're releasing)

    • $ git push origin 2.3.1

  • If you are using post-release incrementing (or if you have previously used pre-release incrementing and want to switch now), increment the version number in and commit the change.

  • Upload the tarball to, by scp-ing it to All module maintainers who wish to be able to upload tarballs should request a shell account at for this purpose -- see AccountPolicy. Ask someone else to do it for you if you are waiting for an account. For example:

    • $ scp gnome-panel-2.3.1.tar.gz (user)

  • Then ssh into and call ftpadmin install. There are no extra steps required for new modules. For example:

    • $ ssh (user) ftpadmin install gnome-panel-2.3.1.tar.gz

    This will move the tarball to the appropriate directory, do some additional administrative stuff, and send an email to the ftp-release mailing list so that the release-team will know about it.
  • If you provide Windows binaries of your package, then scp these to, placing them into e.g. /ftp/pub/GNOME/binaries/win32/gnome-panel/2.3/. You will need to create a directory for your project if there isn't one already. Also make sure to add contact information into /ftp/pub/GNOME/binaries/win32/README in this case. Finally, make sure to add a SOURCES file detailing how to build the binaries. When you are done, run signal-ftp-sync on

MaintainersCorner/Releasing (last edited 2015-10-27 22:02:38 by MichaelCatanzaro)