Release Notes
Contents
For every 6-monthly GNOME release, we write release notes describing the major user-visible changes, along with a general description of GNOME.
We write these in Mallard format, in the release-notes Git repository. They are published on library.gnome.org.
Notes on what to include are assembled in an issue filed against the release-notes project.
Please see previous versions of the release notes for a guide.
Style guidelines
- The release notes should be written in straightforward U.S. English. Use unambiguous and familiar words.
- Don't try to charm or misdirect your way past perceived lack of progress or your lack of understanding. A lot of emotive or enthusiastic language often doesn't go down well, so keep the text factual.
- Explain why new features are helpful, relevant, and positive. Don't assume knowledge on the part of your readers.(But do mention useful technical information in the developers section.)
Taking screenshots
Please follow the standard guidelines when making screenshots for the release notes, including translations.
Screenshots should be 940 pixels wide.
Schedule
The release notes wiki page to collect material example should be created early in the development cycle. You can use the previous release's page as a template.
Developers should be encouraged to add to it as code changes land.
6 weeks before release: call for items
If it doesn't exist already, create an issue on Gitlab to collect release notes content.
Send email to desktop-devel-list AT gnome DOT org, asking for people to add to comment or reference the collection issue by referencing the issue "slug" in a comment on any merge request or issue (example).
- Get agreement on a release name. It ends up going into multiple things (release notes, screenshots, banner images, etc), and coordinating a release name after the fact is a major hassle. The scheme we've been following is to use the most recent major conference location (Guadec for the fall release, GNOME Asia for the spring). With conferences being onlines, we resorted to fantasy names, following a 'universal' or 'world' theme.
4 weeks before release: start writing
Create a new Git branch for the release (follow MaintainersCorner#Branches).
- It helps to clear out the old content from the previous branch, leaving the structure in place, to be filled in.
- Uncomment all items from the list of supported languages.
- Bother people who have not provided information for the wiki page (use IRC, send emails, knock on doors). Mention your deadline because people often think they have until the actual release date to reply.
Contact av, barthalion, or fredp in #sysadmin on IRC to add an entry to the library-web excludes list. The list is /srv/http/library-web/extra/conf/lgorc.
3 weeks before release: review
- Submit a draft for review to a small group of people (ask for volunteers in the Engagement and Documentation channels).
- Start making screenshots.
2 weeks before release: finish writing
- Tell gnome-i18n AT gnome DOT org that translating can begin.
1 week before release: finalise details
Update the Git statistics at the index page. AndreKlapper often helps with this; alternatively there are two scripts you can use to generate the statistics yourself: gnome-gitlab-pull-all-projects and gnome-git-activity-statistics
Use Damned Lies to find out which languages are supported in the new release, and comment out items from the supported languages list accordingly. Then update the number of supported languages.
Release Day
Get a friendly sysadmin to remove the lock from the release notes page.