> On 31 Dec 2015, at 14:13, scl <scl.gplus@xxxxxxxxx> wrote: > > >> And the steps after that are to automate the process > > This reminds me of my attempts to integrate an OS X build slave > into the Jenkins continuous build environment. Sam Gleske or > Tobias Vogel might be able to tell you more about the current state. We’ve been in contact with Tobias indeed. > I you need somebody to test your OS X build related commits, > I can be there. It would be great if you could help with testing new DMG release before we officially release them! > - Splitting the 2.8 and master builds in the modulesets and > moving the master builds into the GIMP master branch. I was thinking of doing that too. > - @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. regards, -kris. _______________________________________________ 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
