Yes, I agree that &quot;stable&quot; releases should be a bit more conservative than the devel branch, but I also would like to see that the &quot;stable&quot; releases contain the best tools available at the time of release. In that regard, I am also happy to hear that the MFD capabilities of r.watershed will be backported to either the 6.4.0 or 6.4.1 releases.<br>
   For future reference, what is the protocol the devel team uses for determining such backports? ie., how does one feature become slated for a backport, while another may not? Is it by popular demand? Or by some quantitative &quot;proof of stability&quot;? Or something else? I&#39;m mainly curious, as I&#39;d like to know if there is a way for &quot;occasional&quot; developers like me to contribute to these decisions, either by intensive module testing, or by clamoring for a change, or by some other means. :)<br>
<br>Cheers,<br><br>Isaac Ullah<br><br><div class="gmail_quote">On Wed, Apr 28, 2010 at 11:01 PM, Hamish <span dir="ltr">&lt;<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">Isaac wrote:<br>
&gt; Why put out the next stable version of GRASS with clearly inferior<br>
&gt; capabilities? This IMO is simple guaranteeing the quick obsolescence<br>
&gt; of the stable GRASS version for anyone actually interested in doing<br>
&gt; state-of-the-art, cutting-edge, robust research with it.<br>
<br>
</div>you can have cutting-edge*, or you can have stable and robust (aka<br>
well-tested). you can&#39;t have both. For &quot;stable&quot; releases it is best<br>
to be intentionally conservative.<br>
<br>
(* the old dumb joke is to call it bleeding-edge because the closer you<br>
get to it the more you get sliced by it)<br>
<br>
e.g. the nasty bug which happened when scripts used uppercase character<br>
flags had its damage limited to development svn builds only and was<br>
flushed out by some months of testing-time.<br>
<br>
<br>
As long as it is planned well in advance and well defined, there is no<br>
big problem to backport the new -f MDF flag to 6.4.x AFAIAC, just don&#39;t<br>
do that in the last few days before release, wait a few weeks for the<br>
next minor point version. There are a couple of other features on a<br>
similar path for 6.4.1. (For releases after x.y.1, I would tend to be a<br>
lot more strict about breaking the &quot;bug fixes only&quot; rule.)<br>
<br>
<br>
regards,<br>
<font color="#888888">Hamish<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Isaac I Ullah, M.A.<br><br>Archaeology PhD Candidate,<br>ASU School of Evolution and Social Change<br><br>Research Assistant,<br>Mediterranean Landscape Dynamics Project<br>
***************************************************<br><a href="mailto:isaac.ullah@asu.edu">isaac.ullah@asu.edu</a><br><a href="mailto:ullah@archaeologist.com">ullah@archaeologist.com</a><br><br><a href="http://www.public.asu.edu/~iullah">http://www.public.asu.edu/~iullah</a><br>
***************************************************<br>