On 10/20/11 5:16 PM, Alexandre Prokoudine wrote: > 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. > >
Absolutely... which will be the case.. but we need to get 1.4.0 released first. Until that is done, we cannot change much. Craig
