luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-03-13 03:05:12 +01:00
Code Issues Packages Projects Releases Wiki Activity
glib/docs/releasing.md
Philip Withnall aea78c9ac7
docs: Tweak release instructions around signing 
Suggest to sign the release commit itself (to keep us in sync with the
Handbook; https://handbook.gnome.org/maintainers/making-a-release.html);
and allow `git tag -s` if `git evtag` is not available (also as per the
Handbook).

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Fixes: #3424
2025-02-04 17:02:04 +00:00

4.4 KiB
Raw Blame History

Making a release

When to make a release

Releases are made on a schedule determined in the roadmap. Each release corresponds to a GitLab milestone.

There is usually some scope to change a release date by plus or minus a week, to allow specific merge requests to land if they are deemed as more important to release sooner rather than waiting until the next scheduled release. However, there is always another release, and releasing on time is more important than releasing with everything landed. Releasing on time allows distributors to schedule their packaging work efficiently.

Maintainers should take it in turns to make releases so that the load is spread out evenly and every maintainer is practiced in the process.

How to make a release

Broadly, GLib follows the same process as every other GNOME module.

These instructions use the following variables:

  • new_version: the version number of the release you are making, for example 2.73.1
  • previous_version: the version number of the most-recently released version in the same release series, for example 2.73.0
  • branch: the branch which the release is based on, for example glib-2-72 or main

Make sure your repository is up to date and doesn’t contain local changes:

git pull
git status

Check the version in meson.build is correct for this release.

Download gitlab-changelog and use it to write a NEWS entry:

gitlab-changelog.py GNOME/glib ${previous_version}..

Copy this into NEWS, and manually write some highlights of the fixed bugs as bullet points at the top. Most changes won’t need to be highlighted — only the ones which add APIs, change dependencies or packaging requirements, or fix impactful bugs which might affect distros’ decisions of how to prioritise the GLib release or how urgent to mark it as.

You can get review of your NEWS changes from other co-maintainers if you wish.

Commit the release:

git add -p
git commit -s -m "${new_version}" --gpg-sign

Test build the release tarball:

meson dist -C build/

Tag, sign and push the release, using ${new_version} as the tag message (see below for information about git evtag):

git evtag sign ${new_version}
git push --atomic origin ${branch} ${new_version}

You will need to temporarily allow maintainers to push to the main branch on https://gitlab.gnome.org/GNOME/glib/-/settings/repository. To use a specific key add an option -u ${keyid|email} after the sign argument.

The dist-job CI job will be triggered and will build and upload the final release archive.

Add the release notes to GitLab and close the milestone:

git-evtag

Releases should be done with git evtag rather than git tag -s, as it provides stronger security guarantees. See its documentation for more details. In particular, it calculates its checksum over all blobs reachable from the tag, including submodules; and uses a stronger checksum than SHA-1.

git tag -a must not be used. Releases must be cryptographically signed to prove that they were made by a maintainer and have not been modified since release.

You will need a GPG key for this, ideally which has been signed by others so that it can be verified as being yours. However, even if your GPG key is unsigned, using git evtag is still beneficial over using git tag.

It is possible to use an SSH key rather than a GPG key — git supports both, although GitLab currently does not support verifying signatures by SSH keys.

See the GNOME Handbook for further information about release signing.