[GRASS-PSC] releases schedule

[Štěpán Turek]

Hi Vasek,




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. 




Periods of release cycle should be discussed.  We also may modify them after
few releases according to practical experience.




Best

Stepan 







"

Inspired by what code sprint people were saying, I put together my proposal.
It counts with release once a year and a half year bugfixing (feature 
freeze) period before the release. I expect comments and criticism and I 
would be glad to compare this proposal with some other proposal.



Vaclav







Releasing and branch management should follow these steps:


   1. have trunk
   2. fork release branch , e.g. release_7_1
   3. only bugfixes to release branch, new features (additions, refactoring,
   documentation) only to trunk
   4. release new version based on release branch, , e.g. 7.1.0
   5. only critical bugfixes go to release branch, release patched version 
   if needed, e.g. 7.1.1, .7.1.2
   6. fork a new release branch (e.g. release_7_2), set old release branch 
   to readonly and continue with point 3.
   



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.


Semantic versioning (http://semver.org/(http://semver.org/)) 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.


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).

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.


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.







On Sat, Mar 29, 2014 at 2:35 AM, Luca Delucchi <lucadeluge at gmail.com
(mailto:lucadeluge at gmail.com)> wrote:
"Hi PSC,

during the code sprint we spoke about releases schedule to improve the
GRASS GIS's quality specially for "our" user experience.
I have no a clear idea about a really good idea. During the code
sprint we spoke about the possibility to release once a year and six
month before put the release branch in freezing mode for testing and
bug fixes.

Could you find a good solution about this topic, I think this is
crucial element for the future of GRASS

Thanks
Best regards

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/(http://gis.cri.fmach.it/delucchi/)
www.lucadelu.org(http://www.lucadelu.org)
_______________________________________________
grass-psc mailing list
grass-psc at lists.osgeo.org(mailto:grass-psc at lists.osgeo.org)
http://lists.osgeo.org/mailman/listinfo/grass-psc
(http://lists.osgeo.org/mailman/listinfo/grass-psc)
"



_______________________________________________
grass-psc mailing list
grass-psc at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-psc/attachments/20140331/cd1f9892/attachment.html>