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

[Blumentrath, Stefan]

Hi,

A user perspective on this discussion:

I would be very, very keen on:
- this: https://trac.osgeo.org/grass/ticket/2579 (as well as the simple python import that is under development) and
- this: https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support and
- this: https://trac.osgeo.org/grass/ticket/2750 and 
- this: https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.what and
- ...

Personally, I perceive GRASS as stable by design and  I very much share Markus N.`s view on GRASS being "my reliable number cruncher".

Backwards compatibility is less of an issue for me, as everybody can update for free. A significant gain in storage, performance and functionality weighs much more for me...

Summarizing: yes reliability is a very important quality of GRASS GIS. Yet, if you feel ready for a release I will embrace the new version (independent from its number), and am definitely willing contribute with testing release candidates... 

Kind regards,
Stefan




-----Original Message-----
From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Markus Metz
Sent: 8. mars 2016 22:36
To: Moritz Lennert <mlennert at club.worldonline.be>
Cc: Martin Landa <landa.martin at gmail.com>; GRASS developers list <grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] is it time to release GRASS71?

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
_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev