> On 31 Dec 2015, at 14:13, scl <scl.gp...@gmail.com> 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,
> 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.
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list