On Wednesday, April 11, 2012 23:03:51 Robin Burchell wrote: > On Wed, Apr 11, 2012 at 2:49 PM, <lars.kn...@nokia.com> wrote: > > We are now done with new feature development and changes to our API. I > > will merge the api_changes branch that contains the remaining changes to > > our api back to master by the end of this week, and close the branch > > after that. > > I wonder: you imply that breaking binary compatibility "in a > controlled way" (by controlling when we stage) is fine - but then why > not keep the branch open for exactly that, and have those controlled > merges 1-2 times a week, and not impede staging? People who need > compile stability can use master (and rebuild once a week), people who > don't mind rebuilding every pull can stick with api_changes, I mean.
> I > was actually initially a bit sceptical, but I don't think it's worked > all that badly as a model, aside from the extended period without a > merge due to the alpha... I think it didn't work well. I'd like to see another model attempted next time, like all commits going to master, and a 'stable' branch which gets fast forwarded once a week - no chance of CI failures, no question of which branch to commit to, and when an alpha needs to be created, a alpha branch can be created, instead of attempting to create it from a still fast-moving master (sort of) with more CI breakage. I'm sure that model won't work 100% for every case either, but if we don't try it, we'll never know for sure. Just for your consideration. Thanks, -- Stephen Kelly <stephen.ke...@kdab.com> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development