mirror of https://github.com/GNOME/gimp.git
194 lines
7.9 KiB
Plaintext
194 lines
7.9 KiB
Plaintext
|
|
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,
|
|
macOS and flatpak 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.
|