Re: [GRASS-dev] is it time to release GRASS71?
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-boun...@lists.osgeo.org] On Behalf Of Markus Metz Sent: 8. mars 2016 22:36 To: Moritz Lennert Cc: Martin Landa ; GRASS developers list Subject: Re: [GRASS-dev] is it time to release GRASS71? On Mon, Feb 29, 2016 at 11:39 AM, Moritz Lennert wrote: > On 28/02/16 00:02, Markus Metz wrote: >> >> On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler wrote: >>> >>> >>> On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: >>>> >>>> >>>> >>>> On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa >>>> >>>> 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
Re: [GRASS-dev] is it time to release GRASS71?
On Mon, Feb 29, 2016 at 11:39 AM, Moritz Lennert wrote: > On 28/02/16 00:02, Markus Metz wrote: >> >> On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler wrote: >>> >>> >>> On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 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
Re: [GRASS-dev] is it time to release GRASS71?
On 28/02/16 00:02, Markus Metz wrote: On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler wrote: On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 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
Re: [GRASS-dev] is it time to release GRASS71?
On Thu, Feb 25, 2016 at 8:56 PM, Markus Neteler wrote: > > On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: >> >> >> On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa >> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
+1 On Thu, Feb 25, 2016 at 2:56 PM, Markus Neteler wrote: > > On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: > > > > > > On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa > 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_newc...@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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On Feb 25, 2016 5:05 PM, "Vaclav Petras" wrote: > > > On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 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
Re: [GRASS-dev] is it time to release GRASS71?
On Feb 25, 2016 4:01 PM, "Martin Landa" wrote: > > 2016-02-25 15:34 GMT+01:00 Moritz Lennert : > >> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On Thu, Feb 25, 2016 at 12:04 PM, Martin Landa wrote: > 2016-02-25 16:37 GMT+01:00 Vaclav Petras : > > 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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
2016-02-25 16:37 GMT+01:00 Vaclav Petras : > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On Thu, Feb 25, 2016 at 9:57 AM, Martin Landa wrote: > 2016-02-25 15:34 GMT+01:00 Moritz Lennert : > >> 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? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On 25 February 2016 at 16:00, Martin Landa 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
2016-02-25 15:34 GMT+01:00 Moritz Lennert : >> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
2016-02-25 15:34 GMT+01:00 Moritz Lennert : >> 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On 25/02/16 13:50, Vaclav Petras wrote: On Thu, Feb 25, 2016 at 1:08 AM, Pietro mailto:peter.z...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On 25/02/16 13:45, Vaclav Petras wrote: Hi, On Thu, Feb 25, 2016 at 4:14 AM, Martin Landa mailto:landa.mar...@gmail.com>> wrote: 2016-02-25 8:59 GMT+01:00 Luca Delucchi mailto:lucadel...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On Thu, Feb 25, 2016 at 1:08 AM, Pietro 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. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
Hi, On Thu, Feb 25, 2016 at 4:14 AM, Martin Landa wrote: > 2016-02-25 8:59 GMT+01:00 Luca Delucchi : > > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
Luca Delucchi writes: > On 25 February 2016 at 07:08, Pietro 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: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
2016-02-25 8:59 GMT+01:00 Luca Delucchi : > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
Hi, 2016-02-25 8:59 GMT+01:00 Luca Delucchi : > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
On 25 February 2016 at 07:08, Pietro 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
