diff options
Diffstat (limited to '')
| -rw-r--r-- | devel-docs/release-howto.txt | 194 |
1 files changed, 194 insertions, 0 deletions
diff --git a/devel-docs/release-howto.txt b/devel-docs/release-howto.txt new file mode 100644 index 0000000..787e66c --- /dev/null +++ b/devel-docs/release-howto.txt @@ -0,0 +1,194 @@ + + How to do a GIMP release + ---------------------------- + a check-list for doing a GIMP release + + ( ) Announce a string freeze on the GIMP Developer mailing list. + + Mention that a release is planned, what branch will be frozen, and + how long the string freeze is going to last. Plan for a couple of + weeks at least. No translatable strings must be touched during + this time. An example announcement message is: + https://mail.gnome.org/archives/gimp-developer-list/2016-October/msg00004.html + + ( ) Announce the planned release on the GNOME I18N mailing list. + + Let them know about the planned release, what branch it's based + on, and how many changes to expect. An example message is: + https://mail.gnome.org/archives/gnome-i18n/2016-October/msg00035.html + + ( ) Also notify the maintainers of the official builds for Windows + (irc:ender/@jernejs), macOS (irc:Samm/@samm-git) and flatpak + (irc:Jehan/@Jehan) of the upcoming release so they have some time + to sort out issues with their builds. + + ( ) Make sure we have a <release> tag inside + desktop/org.gimp.GIMP.appdata.xml.in.in for this upcoming + version, with type="development" for development or RC releases + (set type="stable", or just no type for stable releases). + + Some installers may feature more prominently software with recent + releases if the appropriate tag was set (e.g. GNOME Software has a + "Recent Releases" category). + + If a description is added, it may be featured in installers and + will be translatable (use <_p> or <_li> tags to make the strings + localizable). So it is better to prepare the description text as + early as possible. + + ( ) Wait until the date specified in the announcements, use this time + to get bug fixes applied which don't modify strings. + + ( ) Check that you have working ssh access to pentagon.gnome.org and + that you are a member of the gimpadmins group. If not, ask + Michael Natterer or Michael Schumacher for assistance. + + ( ) Check that download.gimp.org has enough space to upload the + release and to place it into the download area. If not, make + place or ask Michael Natterer or Michael Schumacher to do that. + + ( ) Check that you have admin access to the GIMP product on + bugzilla.gimp.org and commit access to the gimp-web module, or + that someone can do the changes for you. + + ( ) Check if NEWS, authors.xml (and the generated AUTHORS), README or + INSTALL need to be updated, as well as any release notes on + gimp.org. Don't forget to add any "Index of new symbols in GIMP + 2.x" to the gtk-doc generated devel-docs. + + ( ) Does the splash screen need to be changed? + + Splash requirements: + + [ ] Accepted license: a libre license, such as CC 0, CC by, CC + by-sa or Free Art. + [ ] XCF file must be provided. + [ ] Minimum size: full HD (splash images will be scaled down to 1/2 + of the main display when too big; but they won't be scaled up. + Therefore anything smaller than fullHD will look tiny and + unsuited on a 4K or higher res display). + [ ] Loading text will appear in bottom quarter, so image contents + must be adapted. + + ( ) If ever the actual release date evolved and is different from the + planned date, update the "date" in the <release> tag of the appdata + in: desktop/org.gimp.GIMP.appdata.xml.in + + ( ) Bump the version number to an even micro in configure.ac and + commit this change. It should be the version number of the + release you are about to make. Releases always have even micro + numbers. + + [ ] In configure.ac, modify gimp_micro_version accordingly. + + [ ] In configure.ac, modify gimp_interface_age accordingly. + + ( ) Make dist tarballs: + + [ ] Start with a checkout of the GIMP tree. Make sure the + checkout is up to date, clean from uncommitted changes. + + [ ] Run 'git clean -x -d -f' (Warning: you will lose any files + that are not added). + + [ ] Run 'git diff'. This should not generate any output, or your + tree has local modifications. + + [ ] Run ./autogen.sh --enable-gtk-doc + + [ ] Run 'make' to do a complete build of the source tree. + + [ ] Run 'make distcheck'. Avoid passing make -j since that can + cause mysterious fails. + + [ ] If changes to generated files are made by the above command + (run 'git diff' to find out), commit+push them and repeat + from the beginning of this sub-section. + + [ ] If there are problems reported by 'make distcheck', fix + them. If you made changes in the tree to get 'make distcheck' + running, commit+push them and repeat from the beginning of + this sub-section. + + [ ] If 'make distcheck' passed and created tarballs, go to the + next item. + + ( ) A successful run of the 'make distcheck' would create the final + dist tarballs. It will include a ChangeLog generated from the + 'git log'. Note that we don't bother with any release commit, + that's what tags are for (see below). + + ( ) Tag the release (don't forget to push the tag) + git tag -s GIMP_2_x_y + git push origin GIMP_2_x_y + + ( ) Bump the version number (past the tagged version) in configure.ac + to the next odd micro and commit this change. GIT versions always + have odd micro numbers. + + [ ] In configure.ac, modify gimp_micro_version accordingly. + + [ ] In configure.ac, modify gimp_interface_age accordingly. + + ( ) Publish dist tarballs: + + [ ] Use `sha256sum` and `sha512sum` to create checksums of the + tarball (tar.bz2). + + [ ] Upload the tarball (tar.bz2) to your home directory on + pentagon.gnome.org. + + [ ] Copy the tarball to its final destination in the download area + (/srv/ftp/pub/gimp/v2.x). Really use "cp" not "mv" or SELinux + will make the uploaded file unreadable to the web server unless + some obscure status bit is toggled. + + [ ] Update the `SHA256SUMS` and `SHA512SUMS` files present in the + same download area by adding the computed sha256 and sha512 + sums. + Note: do not add new MD5 sums anymore. They are considered + unsafe. + + [ ] Update the 0.0_LATEST-IS- file in the corresponding directory + on the download server. + + [ ] Change permissions of the new files to make them writable by + the 'gimpadmins' group. This will allow other members of this + group to correct mistakes and to update the 0.0_LATEST-IS- + file next time. + + ( ) Add the new version to the GIMP product on bugzilla.gimp.org. + + ( ) Check out or update the 'gimp-web' module, check out its testing + branch. + + [ ] Update the file 'GIMP_VERSIONS' adding the version, release + date, tarball name and its SHA256 and SHA512 hashes under + "STABLE". + Note: do not add new MD5 sums in 'GIMP_VERSIONS' as well. + + [ ] Create a news items for the release in content/news/ + + [ ] Run `make authors.md` in GIMP repository. This will generate + the file `authors.md`. Move it to ./content/about/authors.md on + the 'gimp-web' module and commit it. + + [ ] Commit and push the changes, the web server should then + update itself soon (it checks for updates every 5 minutes). + Go to https://testing.gimp.org to verify the changes. + + ( ) Announce the release on gimp.org and send a release announcement + to the gimp-user and gimp-developer mailing lists. + + [ ] Check out the gimp-web master branch and merge or cherry-pick + the changes you did in the testing branch. + + [ ] Push the changes, the web server should then update itself + soon (it checks for updates every 15 minutes). + Go to https://www.gimp.org to verify the changes. + + [ ] Due to the tendency of news sites to front-run release + articles even before actual announcements appear, publish + everything as fast as possible. + + ( ) Grab a properly chilled beverage and enjoy yourself. |