Making a new release of Maps

This page describes how we currently make a release of Maps today. It would be awesome if more people were interested in helping out with this, creating a small Maps release team. Perhaps taking turns performing the next release or backporting fixes and releasing from stable branches.

Who gets to create and publish a release?

  • In order to create and tag a release commit you need GNOME git access
  • In order to publish tar files on you need to be listed as maintainer in the DOAP file

To get GNOME git access you need to follow the instructions here. The first statement reads:

  • We do request that applicants have submitted a reasonable number of patches to an existing maintainer, or bugzilla reports before they request direct commit access.

To be listed in the DOAP file you should talk to existing maintainers about getting on board the release making team.

Creating and tagging the release commit

A release of Maps is accompanied by a git commit. The commit will change the package version in And also update the NEWS file, indicating what changes have been done since the last release. An example of a release commit can be viewed here

The release commit is also tagged using a signed tag, for example:

$ git tag -s v3.21.90

For this to work you need to have a GPG key.

The NEWS entry

The NEWS file update should contain the most important changes since last release. Indicate if something is extra important. And give credit to all authors of the release. Finding all authors of a release can be done with a command like

$ git log v3.20.2.. --format="%aN <%aE>" --reverse | sort | uniq

You can look at old NEWS file for inspiration, but should not feel limited to that style.

$ git add NEWS
$ git commit -m "Release 3.21.4"
$ git tag -s v3.21.4
$ git push origin master
$ git push origin v3.21.4

Creating the tar file

Before pushing the release commit to we should make sure that we have a working release. And that we are able to create a tar file out of it. This is done for us by using the autoconf rule of distcheck. I usually go:

$ git clean -fxd
$ jhbuild make # or another way of building
$ jhbuild make distcheck

This will run checks to make sure that the tar archive contains the same stuff as when building from source. And will create the tar archive for us, using the version found in If this fails, we need to fix up the errors that prevents us from running distcheck and then redo the release commit.

Uploading the tar file

To publish the release and trigger mail to release lists we need to put our tar archive on

  $ scp gnome-3.21.4.tar.xz

And then we ssh to and run

  $ ftpadmin install gnome-3.21.4.tar.xz

And we are done! For more information check the maintainers corner on the same subject.

Apps/Maps/MakeRelease (last edited 2016-08-22 05:26:49 by JonasDanielsson)