Making a release essentially consists of converting GNOME's BuildStream projects to use tarballs instead of git, building it to make sure all the tarballs actually build together, publishing the result on master.gnome.org, and then announcing the release.
- Shell account to master.gnome.org with 'ftpadmin' group (ability to change /ftp/pub/GNOME)
- GNOME git account
- Familiarity with release process for individual GNOME modules
- Running ssh-agent
Put the following in ~/.ssh/config (even if your username matches the one on master.gnome.org!):
Host *.gnome.org User yourusername
Setting up testing machine
You'll need to clone the gnome-build-meta and releng repos:
$ git clone email@example.com:GNOME/gnome-build-meta.git $ git clone firstname.lastname@example.org:GNOME/releng.git
Simple release walkthrough
As an example, let's assume you're making the 3.27.90 release.
- gnome-desktop includes the gnome-version.xml file that is used to display version information in the gnome-control-center details panel.
- The first step of every GNOME release is to release a new gnome-desktop tarball with a matching version number.
- (This walkthrough assumes you are already familiar with the process for releasing individual modules.)
Run tarball conversion
- Ensure you don't have any local changes to gnome-build-meta and that you are on the master branch. For stable releases, beware that you cannot do releases from the stable branch. You must use the master branch. This is a defect in our release process.
- Update your gnome-build-meta checkout with 'git pull'.
- In project.conf in gnome-build-meta, remove the following lines:
# Store source refs in central project.refs file ref-storage: project.refs
- cd into releng/tools/smoketesting
- For development releases, update tarball-conversion.config if there are new download locations, module renames, or new modules.
- For stable releases, update tarball-conversion-stable.config. Copy it from tarball-conversion.config if this is the first stable release of the cycle. It is important to add limit values for actively developed modules; otherwise, development releases will creep into your stable release! The limit attribute works by specifying the too-new version. E.g. if 3.27 is the current development stream, you want to put limit="3.27" to restrict your release to picking up only the latest 3.26.x tarball.
Run script to create the versions file and update the BuildStream projects:
$ ./convert-to-tarballs.py -v 3.27.90 -d ~/path/to/gnome-build-meta/
This script examines every element in the gnome-build-meta project that uses git, and attempts to replace it with a tarball instead, respecting the tarball locations and version limits specified in tarball-conversion.config.
Build the moduleset
BuildStream workspaces will pollute your build, and you will likely forget about open workspaces. Always start by closing your open workspaces:
$ bst workspace close --all
Copy the ref for freedesktop SDK from junction.refs to freedesktop-sdk.bst.
- If strict build plan has been disabled in ~/.config/buildstream.conf, reenable it. You must use strict build plan to avoid broken releases:
# This configuration reduces the amount of necessary rebuilds #projects: # gnome: # strict: False
- Test the build:
$ bst --log-file build.log build --track-all core.bst
You'll probably encounter several build failures, which you'll need to fix, either by manually updating the tarball versions used in the BuildStream projects, or hounding maintainers to make new releases and then re-running ./convert-to-tarballs.py. Don't hesitate to manually downgrade tarball versions as needed to get a successful build, but if you do so, be sure to nag maintainers to get the problem fixed before the next release.
Once you've fixed the build failures, update the version-controlled versions file under releng/tools (one directory above smoketesting), then push your changes to the releng repository. If working on an unstable release, do not push your changes to gnome-build-meta. <s>If working on a stable release, then you actually do want to push your changes, but only to a stable branch (e.g. gnome-3-28). If you're handling the .0 release you'll need to create that branch yourself.</s> FIXME: Currently we can't build stable releases off of the stable branch, so this advice makes no sense. HELP!
- There's probably an easier way to do this:
$ cd gnome-build-meta $ git commit -am 'do not push' $ git archive --prefix gnome-3.27.90/ -o gnome-3.27.90.tar @ $ xz gnome-3.27.90.tar $ git reset @^
It's worth saying twice: Do not push your changes to gnome-build-meta unless you are working on a stable release and pushing to a stable branch.
If you're working on a stable release, be sure to push a git tag as well.
Publishing on master.gnome.org
Once you've built everything, it's time to publish it.
- Copy files to master.gnome.org, then ssh in:
$ scp gnome-build-meta/gnome-3.27.91.tar.xz master.gnome.org: $ scp releng/tools/smoketesting/versions master.gnome.org: $ ssh master.gnome.org
- Install the release. Note that 'cp -a' is to preserve the correct permissions. The files being copied should be world-readable. Also note that when running 'simple-news', the first argument is the previous release, and the second argument is the current release.
$ mkdir -p /ftp/pub/GNOME/teams/releng/3.27.90 $ cp -a ~/gnome-3.27.90.tar.xz ~/versions /ftp/pub/GNOME/teams/releng/3.27.90 $ ftpadmin release-suites 3.27.90 ~/versions $ ftpadmin simple-news 3.27.3 3.27.90 $ signal-ftp-sync
- Optionally, you can use the output of 'ftpadmin simple-diff' to nag maintainers not providing updates:
$ ftpadmin simple-diff 3.27.3 3.27.90 $ ftpadmin simple-diff --same 3.27.3 3.27.90
- Send an announce mail to desktop-devel, devel-announce, and (if doing a stable release) gnome-announce.
Extra steps for .0 release
- Create new stable branch in gnome-build-meta and push your work there
- Create a new stable flatpak runtime
- Branch gnome-sdk-images
- Replace git references by tarballs in org.gnome.Sdk.json.in, update version in Makefile
- Ask Alex to build it
- Remember to mention the release name (most recent GUADEC/GNOME.Asia host city)
- Update the -stable files (tarball-conversion.config and versions)
- Update the schedule scripts in the releng module to reference the new schedule files (to receive automatic mails)
- Make sure www.gnome.org is updated to note the new release (gnome-web-list is the contact, right?)
- Remove the authentication on library.gnome.org/misc/release-notes/X.Y (ask a gnome-sysadmin to edit the apache config and reload the server; e.g. #sysadmin on irc.gnome.org)
- Make sure a LiveCD and VM machines are out
- Get someone to send out the press release if there's one (tell the board when the release will happen)
- Announce on gnome-announce-list and on devel-announce-list (coordinate with #engagement for social media)
Update www.gnome.org/start/ so that it refers to the correct stable and unstable releases
Currently sysadmin-only, ask sysadmin to edit /etc/apache2/sites-enabled/www.gnome.org on socket and do a service apache2 reload. The content of www.gnome.org/start currently lives behind www.gnome.org/wp-admin.php. Best to talk to the website people for updating this and other website content.
Update links in ReleasePlanning
- Create jhbuild modulesets for the next development cycle
Make sure the new schedule is available as ics (git location: gnomeweb-wml/www.gnome.org/start/schedule-unstable.ics) and on the wiki
The ical.py creates this, see releng module, tools/schedule directory. new www.gnome.org still redirects to old GNOME for the ics file
Some other things we should put in a check list:
- Have screenshots of a default GNOME (so users know what it will look like)
- Have screencasts to demo some new features
- Keep www.gnome.org/getting-gnome up-to-date wrt to stable distro releases and GNOME versions