
                        How to do a GIMP release
                      ----------------------------
                  a check-list for doing a GIMP release

 ( ) 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 and
     Flathub have 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.

 ( ) 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

     This rule is important for stable releases but can be more lax for
     unstable releases.

 ( ) 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

 ( ) Notify the maintainers of the official builds for Windows
     (irc:ender/@jernejs), macOS (irc:Samm/@samm-git and
     irc:DesMcG/@DesMcGuinness) and flatpak (irc:Jehan/@Jehan,
     @harrymichal and @hfiguiere) of the upcoming release so they have
     some time to sort out issues with their builds.

 ( ) Freeze the repository a few days before release, except for
     absolute obvious bug fixes. Ask packagers to make a test package
     based on current HEAD of the release branch. Post links to these
     test packages on a bug report titled "GIMP X.Y.Z release testing".
     Propose all willing testers to try these packages.

 ( ) 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 master.gnome.org and
     that you are a member of the gimpftpadmin group. If not, ask
     Michael Natterer, Michael Schumacher or Jehan 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, Michael Schumacher or Jehan to do
     that.

 ( ) Check that you have admin access to https://gitlab.gnome.org/GNOME/gimp/
     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
     3.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.

 ( ) Make sure that changes which would deserve some tour get the
     appropriate "demo" attribute in desktop/org.gimp.GIMP.appdata.xml.in
     as documented in README.md.

 ( ) 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

 ( ) Check that our Continuous Integration builds are working fine for
     the branch we plan to release: https://gitlab.gnome.org/GNOME/gimp/-/pipelines
     Check that all jobs are successful because we should not release
     with code known not to build in some conditions.

     The following procedure allows to simulate a release:

     [ ] Go to https://gitlab.gnome.org/GNOME/gimp/-/pipelines

     [ ] Click the "Run pipeline" button.

     [ ] Choose the appropriate branch and add the variable
         `CI_COMMIT_TAG` to any value (it will simulate a build with a
         tag, which is characteristical of a release).

     [ ] The following jobs should be triggered:
         build-image, deps-debian, gimp-distcheck-debian, sources,
         deps-win32-native, gimp-win32-native, packaging-win32-native,
         deps-win64-native, gimp-win64-native, packaging-win64-native
         and win-installer-nightly.

     [ ] Check in particular:
         * the job `win-installer-nightly` should contain a working
           Windows installer and 2 checksum files;
         * the job `sources` should contain a tar.bz2 tarball and 2
           checksum files.

     If these steps work fine, we are ready to tag and publish.

     Note: the test build will likely take up to 2 hours, especially
     because of the Windows installer step. And of course, if you ever
     discover any build or run into issues, the time will be multiplied.
     It is advised to take this in consideration. This test step could
     possibly be run well in advance, even the day before, considering
     you don't plan to push too many changes at the last minute.

 ( ) 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.

 ( ) Bump the version in project() of meson.build identically as the
     version set in configure.ac.

 ( ) Commit the version bumps only and push these. Since there was no
     code change since the last CI check, the CI should build fine once
     again. Make sure of it.

 ( ) Tag the release (don't forget to push the tag)
       git tag -s GIMP_2_x_y
       git push origin GIMP_2_x_y

     All release tags are signed in order for the authenticity and
     origin of the release to be publicly verified.

 ( ) Gitlab will run a new CI pipeline specifically for the tag.
     Once it is done, you will find a tarball, a Windows installer,
     SHA256 and SHA512 checksum files on the artifacts of the job
     `sources` and `win-installer-nightly`.
     Direct links, for instance for the GIMP_2_99_6 tag, would be:

     https://gitlab.gnome.org/GNOME/gimp/-/jobs/artifacts/GIMP_2_99_6/browse/?job=sources
     https://gitlab.gnome.org/GNOME/gimp/-/jobs/artifacts/GIMP_2_99_6/browse/?job=win-installer-nightly

 ( ) Ask the Windows installer maintainers to test the installer then to
     sign it if all looks fine.

 ( ) Publish dist tarballs:

     [ ] Upload the 3 files (tar.bz2 tarball and 2 checksums) to
         /gimp_ftp/incoming/ on master.gnome.org (do not upload to your
         home first as it would mess up some SELinux flags).

     [ ] Copy the tarball to its final destination in the download
         area (/gimp_ftp/pub/gimp/). 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 'gimpftpadmin' group. This will allow other members of
         this group to correct mistakes and to update the
         0.0_LATEST-IS- file next time.

 ( ) 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.

 ( ) Bump the version number in meson.build to the same value as in
     configure.ac.

 ( ) Add the next version milestone on GIMP's Gitlab:
     https://gitlab.gnome.org/GNOME/gimp/-/milestones

     Note: we don't close immediately the milestone of the just-released
     version as we may still assign some reports to it, but older
     milestones might be closed (up to what feels the most needed for
     organization of reports).

 ( ) Publish the Windows installer with a similar procedure to the
     source tarballs. The checksum files will probably have to be
     regenerated after the installer's signature.

 ( ) Check out or update the 'gimp-web' module, check out its testing
     branch.

     [ ] Update the file 'content/gimp_versions.json' adding the
         version, release date, tarball name and its SHA256 and SHA512
         hashes under "STABLE" for stable releases or "DEVELOPMENT" for
         dev releases, as well as for any already available packages.
         Note: do not add new MD5 sums anymore.

     [ ] 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 to the `testing` branch, 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.

     [ ] Do not merge to `master` branch yet. We usually wait for a few
         packages to be available (often at least the Flatpak and
         Windows installer) and published to the download server when
         relevant.

     [ ] For binary packages, we also usually publish web torrent files
         with the `tools/download/mt` tool. Here is an example of
         command as run for the revision 2 of GIMP 2.10.24 installer:

           $ tools/downloads/mt -c "GIMP 2.10.24 Installer for Microsoft Windows - 32 and 64 Bit - Update 2: custom GTK fixes for drag&drop issues with certain screen grabbers (issue #1082), tiny SVG icons (issue #1563) and pasting images from some other applications (issue #3481)" -p "v2.10/windows" -m "./tools/downloads/downloads.http.txt" gimp-2.10.24-setup-2.exe

     [ ] Check regularly that most (ideally all) mirrors synced the new
         files. The following commands allows to query all mirrors:

           $ tools/downloads/update-mirrors.py --ssh-user $SSH_USER # where $SSH_USER is your user on download.gimp.org server.
           $ tools/downloads/gimp-check-mirrors.py https://download.gimp.org/mirror/pub/gimp/v2.10/windows/gimp-2.10.24-setup-2.exe

         We want to hold the news a bit because if we publish without
         binary installers, everyone desperately search for them; and if
         we publish with most mirrors lagging behind, many download
         errors will occur.

 ( ) When confident about the installers availability, if this is a
     stable release, create a new package on the Microsoft Partner
     Center so that GIMP becomes available on the Microsoft Store:
     https://partner.microsoft.com/en-us/dashboard/apps-and-games/overview

     The URL to provide is the mirror URL, not the direct URL.

     Current people with admin access to this platform:
     irc:ender/@jernejs and irc:Jehan/@Jehan.

 ( ) 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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Optional: debug the source tarball
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The source tarball is now created by the `gimp-distcheck-debian` CI job.
Nevertheless in case it were to fail, and you need to debug or
exceptionally create your own local tarball for publishing, here would
be the manual version:

 ( ) Make dist tarballs [DEPRECATED - taken from CI jobs]

     🛈 These instructions are left for information purpose and so that
     maintainers remember the way to test locally that distribution
     tarball creation works fine. Nevertheless this is already what the
     continuous integration does (jobs `gimp-distcheck-debian` and
     `sources` in particular) from a clean slate. So as we check the CI
     success, this step is now unecessary. Moreover we should now always
     publish the tarball prepared by the CI, not by a local build, for
     purpose of process transparency.

     [ ] 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).
