In my experience running QA teams and releases for commercial projects, small fast releases require (or imply) quite a bit of focused process and really good automation on the testing side. <br><br>Also, after other discussions on this list, it seems like there are two other items that drive 'major release' twice a year and a few bug fix releases in between:<br>
<br>1 - Our target users (mostly schools) will not be upgrading often, and many will require weeks or months of their own testing before they do upgrade thousands of computers. <br><br>2 - From a support perspective, this audience will probably require that we support a major release for an entire school year. If we offer too many releases during that time, we will not be able to keep up with the backward compatibility matrix of releases that have to work with other releases. If kids upgrade on their own, will they work with the older version that was installed on 90% of the other laptops, etc.<br>
<br>I think if our product were aimed at developers or if it was a server-based product where we could control the releases and there were no backward compatibility problems, then it would be great to have many small, fast releases.<br>
<br>Kim<br><br><br><div class="gmail_quote">On Thu, Apr 17, 2008 at 7:54 AM, Marco Pesenti Gritti <<a href="mailto:mpgritti@gmail.com">mpgritti@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, Apr 17, 2008 at 1:23 PM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:<br>
>  I see this too as a hard problem and don't really have experience<br>
>  neither. What I would expect is that working on frequent time-based<br>
>  releases with features slipping as needed works best for projects like<br>
>  linux distros, where slipping a feature grossly means not updating a<br>
>  set of packages to the latest stable version.<br>
<br>
</div>Even linux distro (Fedora at least,), doesn't actually do focused<br>
releases. Roughly, they set a timeframe and they get in everything<br>
which is ready by that date. This is very easy for a linux<br>
distribution. It would be harder on the Sugar codebase but still very<br>
much feasible, it's the same approach of GNOME releases.<br>
<br>
Though Michael proposal goes a step further. We would be focusing only<br>
on one (or a very limited number) of goals per release.<br>
<font color="#888888"><br>
Marco<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br>