Re: [Gimp-developer] Testers requested for our new Mac OS X DMG release!,



On Mon, Jan 4, 2016 at 11:23 AM, Kristian Rietveld wrote:

- @GIMP team: I remember that at the time I was more active
new versions came out of a sudden when Mitch had time to
bump a release and the releases were made later. This has the
effect that users who read the announcement have to wait
again and thus are disappointed after a long period of waiting
for a release.
How about reorganizing the process of release builds and
version announcements by
1. negotiating a release date internally,
2. completing the release docs (NEWS, 
http://wiki.gimp.org/index.php?title=Special%3APrefixIndex&prefix=Release%3A&namespace=0)
3. bumping the version number,
4. making and testing the builds and
5. as last step announcing the release?

More coordinated releases would be a good thing to have IMHO. Releasing Windows & Mac binaries and perhaps 
Debian/Ubuntu and Fedora packages at the same time as a new tarball release would be great.

Was thinking of exact same thing lately :) But I'd take it further than that.

Not only we have lagging Win/Mac/Linux builds, we also have lagging
user manual releases.

For instance, gimp-help 2.8.0 was released as a tarball in June 2012,
a month after GIMP 2.8.0 release. The installers for Windows only
appeared in August, and we don't even have official OSX builds of the
user manual at all (the ones by Simone are outdated and only available
for a few languages).

Hence I'd like to propose the following change to the release policy,
using Sven's proposal as a basis:

1. Negotiate a release date between mitch (GIMP maintainer), pippin
(GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).

2. Finalize a list of changes that should be covered in the user
manual and in the docs for developers.

3. Announce a strings freeze at least a month before releasing to give
translators and docs writers do their job.

4. Complete all release related docs.

5. Bump version number for both GEGL/babl, GIMP, and gimp-help.

6. Make and test all builds for all supported systems.

7. Update the 'testing' branch of the website (download links,
announcements), update docs.gimp.org, check everything.

8. Merge all changes from the 'testing' branch into the 'master' branch of wgo.

9. Announce.

To specifically aid #2, since December, there's a changelog targeted
at user manual writers:

http://wiki.gimp.org/wiki/Release:2.10_changelog

Needless to say, it's WIP, but it's getting there.

Alex



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]