diff --git a/devel-docs/Makefile.am b/devel-docs/Makefile.am index 74a4a6c557..2bed4347db 100644 --- a/devel-docs/Makefile.am +++ b/devel-docs/Makefile.am @@ -13,7 +13,6 @@ EXTRA_DIST = \ debug-plug-ins.txt \ includes.txt \ parasites.txt \ - release-howto.txt \ tagging.txt \ ui-framework.txt \ undo.txt diff --git a/devel-docs/README.md b/devel-docs/README.md index 142c7c949d..3b0e9bad40 100644 --- a/devel-docs/README.md +++ b/devel-docs/README.md @@ -368,7 +368,7 @@ packages to be generated with the MR code as explained in Special pipelines happen when pushing git `tags`. These should be tested before a release to avoid unexpected release-time issues, as explained -in [release-howto.txt](release-howto.txt). +in [our release procedure](https://developer.gimp.org/core/maintainer/release/). ### Exception: macOS diff --git a/devel-docs/release-howto.txt b/devel-docs/release-howto.txt deleted file mode 100644 index cdea93a8b3..0000000000 --- a/devel-docs/release-howto.txt +++ /dev/null @@ -1,319 +0,0 @@ - - How to do a GIMP release - ---------------------------- - a check-list for doing a GIMP release - - ( ) Make sure we have a 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). - - ( ) Announce a string freeze on GNOME discourse with the `gimp` and `i18n` - tags: - https://discourse.gnome.org/new-topic?title=gimp-x-y%20branch%20string%20freeze%20until%20YYYY-MM-DD&category=Applications&tags=gimp,i18n - - It serves as both an announcement to developers and translators. - - Mention: the planned release version, the frozen branch and the expected - release date (end of freeze). Plan for a couple of weeks at least. No - translatable strings must be touched during this time. - - ( ) 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. - - ( ) 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 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-autotools - gimp-meson-debian sources-meson - dev-docs - deps-win32-native gimp-win32-native packaging-win32-native - deps-win64-native gimp-win64-native packaging-win64-native win-installer-nightly - - [ ] Check in particular: - * the job `win-installer-nightly` should contain a working - Windows installer and 2 checksum files; - * the job `sources-autotools` should contain a tar.bz2 tarball and 2 - checksum files. - * the job `sources-meson` should contain a tar.xz tarball and 2 - checksum files. - * the job `dev-docs` should contain a tar.xz 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 1 hour, 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. - - ( ) 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 - - 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 - previously created Discourse thread. - - [ ] Check out the gimp-web `master` branch and `merge` the `origin/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).