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@lists.osgeo.org] On Behalf Of Markus Metz
Sent: 8. mars 2016 22:36
To: Moritz Lennert <mlennert@club.worldonline.be>
Cc: Martin Landa <landa.martin@gmail.com>; GRASS developers list <grass-dev@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@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@osgeo.org> wrote:
On Feb 25, 2016 5:05 PM, "Vaclav Petras" <wenzeslaus@gmail.com> wrote:
On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa
<landa.martin@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev