devel-docs/release-howto.txt

   1
   2                         How to do a GIMP release
   3                       ----------------------------
   4                   a check-list for doing a GIMP release
   5
   6  ( ) Announce a string freeze on the GIMP Developer mailing list.
   7
   8      Mention that a release is planned, what branch will be frozen, and
   9      how long the string freeze is going to last. Plan for a couple of
  10      weeks at least. No translatable strings must be touched during
  11      this time. An example announcement message is:
  12      https://mail.gnome.org/archives/gimp-developer-list/2016-October/msg00004.html
  13
  14  ( ) Announce the planned release on the GNOME I18N mailing list.
  15
  16      Let them know about the planned release, what branch it's based
  17      on, and how many changes to expect. An example message is:
  18      https://mail.gnome.org/archives/gnome-i18n/2016-October/msg00035.html
  19
  20  ( ) Also notify the maintainers of the official builds for Windows,
  21      macOS and flatpak of the upcoming release so they have some time to
  22      sort out issues with their builds.
  23
  24  ( ) Make sure we have a <release> tag inside
  25      desktop/org.gimp.GIMP.appdata.xml.in.in for this upcoming
  26      version, with type="development" for development or RC releases
  27      (set type="stable", or just no type for stable releases).
  28
  29      Some installers may feature more prominently software with recent
  30      releases if the appropriate tag was set (e.g. GNOME Software has a
  31      "Recent Releases" category).
  32
  33      If a description is added, it may be featured in installers and
  34      will be translatable (use <_p> or <_li> tags to make the strings
  35      localizable). So it is better to prepare the description text as
  36      early as possible.
  37
  38  ( ) Wait until the date specified in the announcements, use this time
  39      to get bug fixes applied which don't modify strings.
  40
  41  ( ) Check that you have working ssh access to pentagon.gnome.org and
  42      that you are a member of the gimpadmins group. If not, ask
  43      Michael Natterer or Michael Schumacher for assistance.
  44
  45  ( ) Check that download.gimp.org has enough space to upload the
  46      release and to place it into the download area. If not, make
  47      place or ask Michael Natterer or Michael Schumacher to do that.
  48
  49  ( ) Check that you have admin access to the GIMP product on
  50      bugzilla.gimp.org and commit access to the gimp-web module, or
  51      that someone can do the changes for you.
  52
  53  ( ) Check if NEWS, authors.xml (and the generated AUTHORS), README or
  54      INSTALL need to be updated, as well as any release notes on
  55      gimp.org. Don't forget to add any "Index of new symbols in GIMP
  56      2.x" to the gtk-doc generated devel-docs.
  57
  58  ( ) Does the splash screen need to be changed?
  59
  60      Splash requirements:
  61
  62      [ ] Accepted license: a libre license, such as CC 0, CC by, CC
  63          by-sa or Free Art.
  64      [ ] XCF file must be provided.
  65      [ ] Minimum size: full HD (splash images will be scaled down to 1/2
  66          of the main display when too big; but they won't be scaled up.
  67          Therefore anything smaller than fullHD will look tiny and
  68          unsuited on a 4K or higher res display).
  69      [ ] Loading text will appear in bottom quarter, so image contents
  70          must be adapted.
  71
  72  ( ) If ever the actual release date evolved and is different from the
  73      planned date, update the "date" in the <release> tag of the appdata
  74      in: desktop/org.gimp.GIMP.appdata.xml.in
  75
  76  ( ) Bump the version number to an even micro in configure.ac and
  77      commit this change. It should be the version number of the
  78      release you are about to make. Releases always have even micro
  79      numbers.
  80
  81      [ ] In configure.ac, modify gimp_micro_version accordingly.
  82
  83      [ ] In configure.ac, modify gimp_interface_age accordingly.
  84
  85  ( ) Make dist tarballs:
  86
  87      [ ] Start with a checkout of the GIMP tree. Make sure the
  88          checkout is up to date, clean from uncommitted changes.
  89
  90      [ ] Run 'git clean -x -d -f' (Warning: you will lose any files
  91          that are not added).
  92
  93      [ ] Run 'git diff'. This should not generate any output, or your
  94          tree has local modifications.
  95
  96      [ ] Run ./autogen.sh --enable-gtk-doc
  97
  98      [ ] Run 'make' to do a complete build of the source tree.
  99
 100      [ ] Run 'make distcheck'. Avoid passing make -j since that can
 101          cause mysterious fails.
 102
 103      [ ] If changes to generated files are made by the above command
 104          (run 'git diff' to find out), commit+push them and repeat
 105          from the beginning of this sub-section.
 106
 107      [ ] If there are problems reported by 'make distcheck', fix
 108          them. If you made changes in the tree to get 'make distcheck'
 109          running, commit+push them and repeat from the beginning of
 110          this sub-section.
 111
 112      [ ] If 'make distcheck' passed and created tarballs, go to the
 113          next item.
 114
 115  ( ) A successful run of the 'make distcheck' would create the final
 116      dist tarballs. It will include a ChangeLog generated from the
 117      'git log'. Note that we don't bother with any release commit,
 118      that's what tags are for (see below).
 119
 120  ( ) Tag the release (don't forget to push the tag)
 121        git tag -s GIMP_2_x_y
 122        git push origin GIMP_2_x_y
 123
 124  ( ) Bump the version number (past the tagged version) in configure.ac
 125      to the next odd micro and commit this change. GIT versions always
 126      have odd micro numbers.
 127
 128      [ ] In configure.ac, modify gimp_micro_version accordingly.
 129
 130      [ ] In configure.ac, modify gimp_interface_age accordingly.
 131
 132  ( ) Publish dist tarballs:
 133
 134      [ ] Use `sha256sum` and `sha512sum` to create checksums of the
 135          tarball (tar.bz2).
 136
 137      [ ] Upload the tarball (tar.bz2) to your home directory on
 138          pentagon.gnome.org.
 139
 140      [ ] Copy the tarball to its final destination in the download area
 141          (/srv/ftp/pub/gimp/v2.x). Really use "cp" not "mv" or SELinux
 142          will make the uploaded file unreadable to the web server unless
 143          some obscure status bit is toggled.
 144
 145      [ ] Update the `SHA256SUMS` and `SHA512SUMS` files present in the
 146          same download area by adding the computed sha256 and sha512
 147          sums.
 148          Note: do not add new MD5 sums anymore. They are considered
 149          unsafe.
 150
 151      [ ] Update the 0.0_LATEST-IS- file in the corresponding directory
 152          on the download server.
 153
 154      [ ] Change permissions of the new files to make them writable by
 155          the 'gimpadmins' group. This will allow other members of this
 156          group to correct mistakes and to update the 0.0_LATEST-IS-
 157          file next time.
 158
 159  ( ) Add the new version to the GIMP product on bugzilla.gimp.org.
 160
 161  ( ) Check out or update the 'gimp-web' module, check out its testing
 162      branch.
 163
 164      [ ] Update the file 'GIMP_VERSIONS' adding the version, release
 165          date, tarball name and its SHA256 and SHA512 hashes under
 166          "STABLE".
 167          Note: do not add new MD5 sums in 'GIMP_VERSIONS' as well.
 168
 169      [ ] Create a news items for the release in content/news/
 170
 171      [ ] Run `make authors.md` in GIMP repository. This will generate
 172          the file `authors.md`. Move it to ./content/about/authors.md on
 173          the 'gimp-web' module and commit it.
 174
 175      [ ] Commit and push the changes, the web server should then
 176          update itself soon (it checks for updates every 5 minutes).
 177          Go to https://testing.gimp.org to verify the changes.
 178
 179  ( ) Announce the release on gimp.org and send a release announcement
 180      to the gimp-user and gimp-developer mailing lists.
 181
 182      [ ] Check out the gimp-web master branch and merge or cherry-pick
 183          the changes you did in the testing branch.
 184
 185      [ ] Push the changes, the web server should then update itself
 186          soon (it checks for updates every 15 minutes).
 187          Go to https://www.gimp.org to verify the changes.
 188
 189      [ ] Due to the tendency of news sites to front-run release
 190          articles even before actual announcements appear, publish
 191          everything as fast as possible.
 192
 193  ( ) Grab a properly chilled beverage and enjoy yourself.