1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
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.
|
