On Thu, Oct 20, 2011 at 7:02 PM, Jan Schrewe wrote: > I personally would opt for releases with smaller changes way more often. And > skip all that we have a development version that we work on for two years > and then take another year to stabilize it and then release it and only fix > bugs. That is a nice model for huge companies who charge a lot of money for > each release. It does not really seem to work for any open source projects.
*skipping most of your mail, sorry* There is quite an effective model of developing major new features in a branch. For instance, Blender folks figured out they need a way to deal with ever-raising amount of GSoC projects, so they develop those in branches, then group them into digestable bits and start merging stuff into new versions one by one. That's what GIMP team is doing now too: Git branches for major features with main development happening in the master branch. As a matter of fact, the reason GIMP 2.8 is so late is pretty much the same why Scribus 1.4.0 is so late. One could learn some important lessons from that :) Given amount of time the existing Scribus team can spare to the project it makes a perfect sense to switch to a manageable development cycle and process. Alexandre Prokoudine http://libregraphicsworld.org
