[GRASS-PSC] releases schedule

[Vaclav Petras]

On Mon, Mar 31, 2014 at 4:35 AM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:

> On 29/03/14 21:56, Vaclav Petras wrote:
>
>> 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.
>>
>
> I find that 6 months is a fairly long period to maintain a bugfix-only
> branch. I would rather propose to either branch later, or to allow more
> than just bugfixes into the release branch for 4-5 months before going into
> bugfix-only phase for the last month or two. During the first period new
> features can be ported to the release branch once they have had some
> testing in trunk.
>
>
Moritz, I believe that these are two different things.

First, the lengths of time periods. First question is how often we want to
release MAJOR.MINOR version. Once a year looks good for me but I have no
special reasons for this. The length of period between fork and release can
be probably anything from 1 month to 6 months. The length of period after
release to next release should be the rest so from 6 month to 11.

Second, committing features to both branches is what is taking the time
from us and creating uncertainty about what is where and what are the
branches for. I think that this is crucial point and the lengths of time
periods above should be decided based on this, not the other way around.

Vaclav


> Moritz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-psc/attachments/20140331/0d7613f0/attachment.html>