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.

1. 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 master.gnome.org 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.

2. Creating and tagging the release commit

A release of Maps is accompanied by a git commit. The commit will change the package version in configure.ac. 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.35.1

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

2.1. 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.34.0.. --format="%aN <%aE>" --reverse | sort | uniq

For stable releases update the <releases> section in data/org.gnome.Maps.appdata.xml.in

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

$ git add meson.build NEWS # data/org.gnome.Maps.appdata.xml.in if applicable
$ git commit -m "Release 3.35.1"
$ git tag -s v3.35.1
$ git push origin master
$ git push origin v3.35.1

3. Creating the tar file

Before pushing the release commit to git.gnome.org 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 dist target of ninja, I usually go:

$ ninja -C build dist

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 meson.build. If this fails, we need to fix up the errors that prevents us from running dist and then redo the release commit. If /tmp is mounted noexec, you might need to set the environment variable TEMP pointing somewhere where scripts can be executed.

4. Uploading the tar file

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

  $ scp gnome-3.21.4.tar.xz master.gnome.org:

And then we ssh to master.gnome.org 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.