[GRASS-dev] is it time to release GRASS71?

[Markus Metz]

On Mon, Feb 29, 2016 at 11:39 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 28/02/16 00:02, Markus Metz wrote:
>>
>> On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler <neteler at osgeo.org> wrote:
>>>
>>>
>>> On Feb 25, 2016 5:05 PM, "Vaclav Petras" <wenzeslaus at gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa <landa.martin at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> this system is used also by QGIS, MapServer, moreover it's part of
>>>>> GRASS history (with one exception - 6.3). I have no strong option
>>>>> about that. I would say let's follow our tradition to use odd numbers
>>>>> for dev versions. Martin
>>>>
>>>>
>>>>
>>>>
>>>> The fact that other OSGeo projects are using it is quite convincing. But
>>>> anyway, I don't see a point in simply skipping a version number.
>>>
>>>
>>> Well, we are using 7.1 visibly for so long as unstable/dev version.
>>> So it sounds perfectly fine to call the result 7.2.
>>
>>
>> Please be aware that because of many partial backports, relbr70 is 1)
>> unstable (as was G6.4) and is in some regards less reliable than
>> trunk.
>
>
> I would say this partly depends on the notion of stable and unstable. Stable
> does not mean perfect. It just means that nothing significant is going to
> change, or ? trunk can sometimes be in a non-functional state while someone
> is introducing new functionality. Normally, stable should never be in a
> non-functional state and when it is, then this is a bug and will be fixed.

Assuming stable means no major changes in the code base will happen, a
releasebranch should be stable and at the same time become more robust
(bugs being eliminated with every z release with GRASS x.y.z).
>
>> Stable typically means backport only of critical bugxfixes.
>
>
> I do completely agree with this, and I agree that we have not been careful
> enough and have succombed to the temptation of backporting some new
> features. That should definitely be a no-go. Once a release is out, only bug
> fixes should go in, no new features. If we want new features to be available
> to users we have to release more often, possibly by releasing development
> snapshots directly from trunk from time to time.

The GRASS release policy is described in the GRASS release roadmap
[0]. A release branch is identified by its major and minor version
number. According to the GRASS release policy, a release branch should
become more robust (have less bugs) with every revision. That implies
that no new features are backported.

Following this policy would imply more frequent releases of more
robust GRASS versions, and earlier availability of new features in a
release branch because developers would (should) push for trunk being
released as a new release branch because nice new features are not
allowed to be backported.

>
>> Therefore, in order to stick with the odd/even numbering meaning, G7
>> should have been released immediately as G71 to indicate a dev
>> version. Not unstable (the code base will remain stable) but a dev
>> version (testing new features). According to the odd/even numbering
>> scheme, current trunk should be released as G7.3 and not G7.2 because
>> it introduces new features.
>
Considering the history of GRASS GIS of the last 6 years, in
particular 6.4, a GRASS GIS release x.y.0 means "new features, expect
bugs". A GRASS GIS release x.y.z means "new features, hopefully less
bugs than in x.y.(z-1), but there can be new bugs".

Markus M

[0] https://grasswiki.osgeo.org/wiki/Release_Roadmap#What_are_these_release_numbers.3F