Skip to content

Latest commit

 

History

History
107 lines (85 loc) · 4.17 KB

RELEASE.md

File metadata and controls

107 lines (85 loc) · 4.17 KB

GNOME Software Release Notes

Release schedule

GNOME Software releases are done on the timetable set by the GNOME release schedule.

Maintainers take it in turns to make releases so that the load is spread out evenly.

Making a release

Adapted from the GNOME release process.

These instructions use the following variables:

  • new_version: the version number of the release you are making, for example 3.38.1
  • previous_version: the version number of the most-recently released version in the same release series, for example 3.38.0
  • branch: the branch which the release is based on, for example gnome-40 or main
  • key_id: the ID of your GPG key, see the output of gpg --list-keys and the note at the end of this file

Go to https://gitlab.gnome.org/GNOME/gnome-software/-/milestones/ and choose the corresponding milestone. Verify all issues and merge requests tagged for this release are complete now. Move those which not to the next milestone or merge pending fixes when possible.

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 release entries:

gitlab-changelog.py GNOME/gnome-software ${previous_version}..

Edit this down to just the user visible changes, and list them in data/metainfo/org.gnome.Software.metainfo.xml.in. User visible changes are ones which the average user might be interested to know about, such as a fix for an impactful bug, a UI change, or a feature change.

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

Generate NEWS file:

appstreamcli metainfo-to-news ./data/metainfo/org.gnome.Software.metainfo.xml.in ./NEWS

Commit the release:

git add -p
git commit -S -m "Release version ${new_version}"

Tag, sign and push the release (see below for information about git evtag):

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

To use a specific key add an option -u ${keyid|email} after the sign argument.

Use Tag ${new_version} release as the tag message.

The release archive will now be built in CI and automatically uploaded to download.gnome.org using the release service.

Post release version bump in meson.build:

# edit meson.build, then
git commit -a -m "trivial: Post release version bump"
git push

Add the release notes to GitLab and close the milestone:

  • Go to https://gitlab.gnome.org/GNOME/gnome-software/-/releases/${new_version}/edit
    • set the Milestone of the release, if such exists
    • copy the Release notes for the new release from the NEWS file, overwriting the description from the git tag (replace ~~~~~~~~~~~~ with === (only three =))
    • in the Links section add:
      URL Link title Type
      https://download.gnome.org/sources/gnome-software/${new_major_version}/gnome-software-${new_version}.tar.xz Release tarball Other
      https://download.gnome.org/sources/gnome-software/${new_major_version}/gnome-software-${new_version}.sha256sum Release tarball sha256sum Other
    • save the changes with Save changes button
    • verify the added links for the release artifacts work
  • Go to https://gitlab.gnome.org/GNOME/gnome-software/-/milestones/ choose the milestone and close it

git-evtag

Releases should be done with git evtag rather than git tag, 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.

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.