[GRASS-PSC] releases schedule

[Vaclav Petras]

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/) 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> 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/
> www.lucadelu.org
> _______________________________________________
> 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/20140329/7cca5866/attachment.html>