<div class="gmail_extra">On Tue, Nov 27, 2012 at 4:01 PM, Anton Vodonosov <span dir="ltr"><<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

In other words the version advertised on ECL web site as the release should<br>
be the best known of existing versions.<br>
<div class="im"></div></blockquote></div><br>Let me clarify the criterion I have used so far for making releases:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* Sufficient number of fixes.</div><div class="gmail_extra">

* I have managed to test the release on all supported platforms.</div><div class="gmail_extra">* I have managed to test and not increase the number of broken libraries.</div><div class="gmail_extra">* Maxima builds and tests fine.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">This has to be done because accumulating fixes does not mean everything stays the same -- sometimes one fix breaks other things --. And so far, with the current git/CVS tree, points 2-4 from this list are not checked.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">In principle one could do more frequent releases but verifying cycles 2-4 usually take several days for me, specially when I cannot rely that automated tests produced the right results. cl-test-grid helps with #3 currently and hopefully I will find a free weekend during my approaching holidays to do #2 and #4, but you realize it is not that easy -- which is why other projects have a release manager.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Juanjo</div><div class="gmail_extra"><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>