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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
