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

GRASS GIS GRASS GIS developer
1

Dear devs,

I saw the discussion on https://trac.osgeo.org/grass/ticket/2750#comment:48

Perhaps is time to think to release the next stable release of GRASS
before that the stable release and trunk start to diverge too much...

What do you think?

Pietro

2

On 25 February 2016 at 07:08, Pietro <peter.zamb@gmail.com> wrote:

Dear devs,

I saw the discussion on https://trac.osgeo.org/grass/ticket/2750#comment:48

Perhaps is time to think to release the next stable release of GRASS
before that the stable release and trunk start to diverge too much...

What do you think?

I support this, but I think it should be 7.2 not 7.1. Usually stable
version is even number
https://trac.osgeo.org/grass/wiki/Release
only 6.3 was an exception

Pietro

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

3

Hi,

2016-02-25 8:59 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

I support this, but I think it should be 7.2 not 7.1. Usually stable
version is even number
https://trac.osgeo.org/grass/wiki/Release
only 6.3 was an exception

7.0.4 is planned for the end of April a version 7.2. somewhere in the
summer (~June). See [1]. Martin

[1] https://trac.osgeo.org/grass/roadmap

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

4

2016-02-25 8:59 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

I support this, but I think it should be 7.2 not 7.1. Usually stable
version is even number
https://trac.osgeo.org/grass/wiki/Release
only 6.3 was an exception

then we should probably rename milestone from 7.1. to 7.2 [1]. Ma

[1] https://trac.osgeo.org/grass/milestone/7.1.0

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

5

Luca Delucchi <lucadeluge@gmail.com> writes:

On 25 February 2016 at 07:08, Pietro <peter.zamb@gmail.com> wrote:

Dear devs,

I saw the discussion on https://trac.osgeo.org/grass/ticket/2750#comment:48

Perhaps is time to think to release the next stable release of GRASS
before that the stable release and trunk start to diverge too much...

What do you think?

I support this, but I think it should be 7.2 not 7.1. Usually stable
version is even number
https://trac.osgeo.org/grass/wiki/Release
only 6.3 was an exception

I would very much like to see OS X El Capitan support to return to 7.2.

Any chance of pushing this a bit?

Rainer

Pietro

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

6

Hi,

On Thu, Feb 25, 2016 at 4:14 AM, Martin Landa <landa.martin@gmail.com>
wrote:

2016-02-25 8:59 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:
> I support this, but I think it should be 7.2 not 7.1. Usually stable
> version is even number
> https://trac.osgeo.org/grass/wiki/Release
> only 6.3 was an exception

then we should probably rename milestone from 7.1. to 7.2 [1]. Ma

What would be the point in skipping the one version? Or why stable and
unstable versions? How many times we did that? Last time we did that was 10
years back. Is it user-friendly? I don't think so.

I don't understand this no odd numbers versioning. Please explain. Thanks,
Vaclav

7

On Thu, Feb 25, 2016 at 1:08 AM, Pietro <peter.zamb@gmail.com> wrote:

Perhaps is time to think to release the next stable release of GRASS
before that the stable release and trunk start to diverge too much...

From where are we branching new release? trunk or stable branch? There was

a discussion about it in past. Is there a clear opinion about that now? I
don't have one but I was for branching from trunk in the past.

8

On 25/02/16 13:45, Vaclav Petras wrote:

Hi,

On Thu, Feb 25, 2016 at 4:14 AM, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:

    2016-02-25 8:59 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com
    <mailto:lucadeluge@gmail.com>>:
    > I support this, but I think it should be 7.2 not 7.1. Usually stable
    > version is even number
    >https://trac.osgeo.org/grass/wiki/Release
    > only 6.3 was an exception

    then we should probably rename milestone from 7.1. to 7.2 [1]. Ma

What would be the point in skipping the one version? Or why stable and
unstable versions? How many times we did that? Last time we did that was
10 years back. Is it user-friendly? I don't think so.

I don't understand this no odd numbers versioning. Please explain.

https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

I don't have a strong opinion either way, as I don't think that this scheme is so strong in people's heads that they would be surprised by a 7.1, it hasn't really been followed much in GRASS' history.

Moritz

9

On 25/02/16 13:50, Vaclav Petras wrote:

On Thu, Feb 25, 2016 at 1:08 AM, Pietro <peter.zamb@gmail.com
<mailto:peter.zamb@gmail.com>> wrote:

    Perhaps is time to think to release the next stable release of GRASS
    before that the stable release and trunk start to diverge too much...

From where are we branching new release? trunk or stable branch? There
was a discussion about it in past. Is there a clear opinion about that
now? I don't have one but I was for branching from trunk in the past.

AFAIU trunk, otherwise it might mean a big effort of backporting, or ?

Moritz

10

2016-02-25 15:34 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

From where are we branching new release? trunk or stable branch? There
was a discussion about it in past. Is there a clear opinion about that
now? I don't have one but I was for branching from trunk in the past.

AFAIU trunk, otherwise it might mean a big effort of backporting, or ?

from trunk for sure. So let's say 2 weeks ago RC1 we create
releasebranch_7_2 from trunk. Then trunk becomes 7.3.svn. At same
point I would suggest to freeze completely releasebranch_7_0 since we
are not planning 7.0.5. The development will continue in trunk and
backports will be done only for releasebranch_7_2. What do you think?
Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

11

2016-02-25 15:34 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

I don't understand this no odd numbers versioning. Please explain.

https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

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

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

12

On 25 February 2016 at 16:00, 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

+1

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

13

On Thu, Feb 25, 2016 at 9:57 AM, Martin Landa <landa.martin@gmail.com>
wrote:

2016-02-25 15:34 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:
>> From where are we branching new release? trunk or stable branch? There
>> was a discussion about it in past. Is there a clear opinion about that
>> now? I don't have one but I was for branching from trunk in the past.
>
> AFAIU trunk, otherwise it might mean a big effort of backporting, or ?

from trunk for sure. So let's say 2 weeks ago RC1 we create
releasebranch_7_2 from trunk. Then trunk becomes 7.3.svn. At same
point I would suggest to freeze completely releasebranch_7_0 since we
are not planning 7.0.5. The development will continue in trunk and
backports will be done only for releasebranch_7_2. What do you think?

I think we make some promises regarding 7.0 and long term support release
in the announcements. How this goes together with not planning 7.0.5?

14

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. I think
Linux kernel was using this odd unstable system in past but they were still
doing the releases with odd numbers.

15

2016-02-25 16:37 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

I think we make some promises regarding 7.0 and long term support release in
the announcements. How this goes together with not planning 7.0.5?

7.2 will become LTS. Otherwise we would need to maintain 3 branches -
trunk, releasebranch_7_2 and releasebranch_7_0. Let's try to maintain
two branches and not more, so trunk and latest release branch. Just 2
my cents, Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

16

On Thu, Feb 25, 2016 at 12:04 PM, Martin Landa <landa.martin@gmail.com>
wrote:

2016-02-25 16:37 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:
> I think we make some promises regarding 7.0 and long term support
release in
> the announcements. How this goes together with not planning 7.0.5?

7.2 will become LTS. Otherwise we would need to maintain 3 branches -
trunk, releasebranch_7_2 and releasebranch_7_0. Let's try to maintain
two branches and not more, so trunk and latest release branch. Just 2
my cents, Martin

The announcements say "As a stable release 7.0 enjoys *long-term support*."
But we don't have any unstable releases (e.g. skipping 7.1) and long-term
support ends as soon as the new release is available, so it may be a year
or two but nothing like Ubuntu LTS. I agree that we should limit the
maintained branches and changes to old branches but we should be clear
about it, so users know what to expect.

17

On Feb 25, 2016 4:01 PM, “Martin Landa” <landa.martin@gmail.com> wrote:

2016-02-25 15:34 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

I don’t understand this no odd numbers versioning. Please explain.

https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

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

+1

Markus

–
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

18

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.

Markus

19

+1

···

On Thu, Feb 25, 2016 at 2: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.

Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. As a federal employee, my email may be subject to FOIA request.

20

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. Stable typically means backport only of critical bugxfixes.
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.

Markus M