<br><br><div class="gmail_quote">On 20 October 2011 17:16, Alexandre Prokoudine <span dir="ltr"><<a href="mailto:alexandre.prokoudine@gmail.com">alexandre.prokoudine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Thu, Oct 20, 2011 at 7:02 PM, Jan Schrewe wrote:<br>
<br>
> I personally would opt for releases with smaller changes way more often. And<br>
> skip all that we have a development version that we work on for two years<br>
> and then take another year to stabilize it and then release it and only fix<br>
> bugs. That is a nice model for huge companies who charge a lot of money for<br>
> each release. It does not really seem to work for any open source projects.<br>
<br>
</div>*skipping most of your mail, sorry*<br></blockquote><div><br></div><div>No worries, you caught the important part ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
There is quite an effective model of developing major new features in<br>
a branch. For instance, Blender folks figured out they need a way to<br>
deal with ever-raising amount of GSoC projects, so they develop those<br>
in branches, then group them into digestable bits and start merging<br>
stuff into new versions one by one. That's what GIMP team is doing now<br>
too: Git branches for major features with main development happening<br>
in the master branch.<br></blockquote><div><br></div><div>This kind of model seems to be the way to go nowadays. Especially since the dvcs tools like git and mercurial are actually able to handle merges without the usual svn pain.</div>

<div><br></div><div>That's one way. Though I would bet that git's forks and pull request and (hopefully) github keeps you going for a long time with maybe two branches and some tags (but then again this gives you something that is similar to branches).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As a matter of fact, the reason GIMP 2.8 is so late is pretty much the<br>
same why Scribus 1.4.0 is so late. One could learn some important<br>
lessons from that :)<br></blockquote><div><br></div><div>Stuff like release early and often, KISS and distributed development models aren't exactly new. These seem to be the lessons learned.</div><div> </div><div>Jan</div>

</div>