On 28/02/16 00:02, Markus Metz wrote:
On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler <nete...@osgeo.org> wrote:
On Feb 25, 2016 5:05 PM, "Vaclav Petras" <wenzesl...@gmail.com> wrote:
On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa <landa.mar...@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.
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.
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.
I think we can possibly release either a series of dev snapshots 7.1.1,
7.1.2, working towards a stable release 7.2. Or we soon create a
releasebranch 7.2 and start stabilising that code, declaring a feature
freeze ASAP and then only ironing out bugs.
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
