<html><body><div><div>Hi Vasek,</div><div><br></div><div>your proposal is identical to my opinion. Taking into account number of developers of GRASS GIS, the proposal seems to me as best solution to avoid recurrence of current state when GRASS 7 has become used as stable by many users as consequence of many years of development without any release. </div><div><br></div><div>Periods of release cycle should be discussed. We also may modify them after few releases according to practical experience.</div><div><br></div><div>Best</div><div>Stepan </div></div><div><br></div><div><br></div><blockquote><div><div>Inspired by what code sprint people were saying, I put together my proposal. It counts with r<span style="font-family:arial,sans-serif;font-size:13px">elease once a year and a half year bugfixing (feature freeze) period </span><span style="font-family:arial,sans-serif;font-size:13px">before the release. I expect comments and criticism and I would be glad to compare this proposal with some other proposal.</span><div>
<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Vaclav</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font><div>
<p>Releasing and branch management should follow these steps:<br>
</p><ol>
<li>have trunk</li>
<li>fork release branch , e.g. release_7_1</li>
<li>only bugfixes to release branch, new features (additions, refactoring, documentation) only to trunk</li>
<li>release new version based on release branch, , e.g. 7.1.0</li>
<li>only critical bugfixes go to release branch, release patched version if needed, e.g. 7.1.1, .7.1.2</li>
<li>fork a new release branch (e.g. release_7_2), set old release branch to readonly and continue with point 3.</li>
</ol>
<p></p>
<p>
It seems that release should be done every year. A new release branch should be forked half a year before planned release. As a consequence, there would be a new branch every year. A new branch is forked from trunk in its current state. Time of forking is specified, so doing larger changes can be postponed if necessary. Alternatively, particular commits can be reverted if necessary. After a half year of bugfixing the release branch (by backports from trunk) we release. In next half a year after release, subsequent patch releases will be provided in case of critical bugs. In this period, almost all changes are in trunk only since only critical bug fixes go to release branch. After this period, new release branch is forked again from trunk and cycle starts again.<br>
</p>
<p>
Semantic versioning (<a href="http://semver.org/">http://semver.org/</a>) will be used (MAJOR.MINOR.PATCH). New releases gets new MINOR if they are backwards compatible, MAJOR if they are not. Critical bugfixes of released version gets new PATCH.<br>
</p><p>When a new development branch is forked, a release candidate (MAJOR.MINOR.PATCH-RC1) or some other pre-release version can be released. This can repeat during the half year of bugfixing of release branch (in random or exact intervals or based on fixed bugs).</p>
<p>
Larger experimental changes (e.g. storage format changes, things like temporal framework) should be done in a separate branch (or repository if more convenient). Then they should be committed to trunk and branch should be set to readonly. Ideal time for introducing new changes is after forking of a new release branch. Situation with some better, although perhaps experimental, branch and a completely separated release branch should be avoided. To make it clear, we should avoid situation when we are developing two versions of GRASS such as 6 and 7, and similarly we should not start development of GRASS 8 by forking branch devel_8.<br>
</p>
<p>
To be sure what we are doing, we should perhaps discuss what are backwards incompatible changes (cases for MAJOR version); we have the following interfaces: GUI, workspace file, GUI API, modules, C API (and ctypes), Python API (to modules and general) and vector, invoking GRASS from command line, raster, 3D raster and temporal database formats.</p>
</div></div></div><div><br><br><div>On Sat, Mar 29, 2014 at 2:35 AM, Luca Delucchi <span><<a href="mailto:lucadeluge@gmail.com">lucadeluge@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi PSC,<br>
<br>
during the code sprint we spoke about releases schedule to improve the<br>
GRASS GIS's quality specially for "our" user experience.<br>
I have no a clear idea about a really good idea. During the code<br>
sprint we spoke about the possibility to release once a year and six<br>
month before put the release branch in freezing mode for testing and<br>
bug fixes.<br>
<br>
Could you find a good solution about this topic, I think this is<br>
crucial element for the future of GRASS<br>
<br>
Thanks<br>
Best regards<br>
<span><font color="#888888"><br>
--<br>
ciao<br>
Luca<br>
<br>
<a href="http://gis.cri.fmach.it/delucchi/">http://gis.cri.fmach.it/delucchi/</a><br>
<a href="http://www.lucadelu.org">www.lucadelu.org</a><br>
_______________________________________________<br>
grass-psc mailing list<br>
<a href="mailto:grass-psc@lists.osgeo.org">grass-psc@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-psc">http://lists.osgeo.org/mailman/listinfo/grass-psc</a><br>
</font></span></blockquote></div><br></div>
</div>_______________________________________________<br>grass-psc mailing list<br>grass-psc@lists.osgeo.org<br>http://lists.osgeo.org/mailman/listinfo/grass-psc</blockquote></body></html>