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 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.
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.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 configure.ac 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 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 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 configure.ac. 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 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.