summaryrefslogtreecommitdiffstats
path: root/devel-docs/release-howto.txt
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--devel-docs/release-howto.txt194
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.