there is the request by the QGIS team to ensure that GRASS 7.4.4 comes
out before 2019-01-18 (release date of QGIS 2.18.28) in order to offer
in Processing the much requested "r.mapcalc.simple", see https://github.com/qgis/QGIS/pull/8444 .
Since it is not too much effort from our side (besides the lately
probably high frequency release cycle for 7.4.x) I would suggest to
get GRASS GIS 7.4.4 out as a "friendship release" for QGIS
The proposed time schedule (https://trac.osgeo.org/grass/milestone/7.4.4):
- Proposal of release: 28 Dec 2018
- Soft freeze of release branch: 30 Dec 2018
- RC1: 2 Jan 2019
- Final release: 15 Jan 2019
Besides r.mapcalc.simple we have three fixes to offer, see
there is the request by the QGIS team to ensure that GRASS 7.4.4 comes
out before 2019-01-18 (release date of QGIS 2.18.28) in order to offer
in Processing the much requested "r.mapcalc.simple", see https://github.com/qgis/QGIS/pull/8444 .
Since it is not too much effort from our side (besides the lately
probably high frequency release cycle for 7.4.x) I would suggest to
get GRASS GIS 7.4.4 out as a "friendship release" for QGIS
The proposed time schedule (https://trac.osgeo.org/grass/milestone/7.4.4):
- Proposal of release: 28 Dec 2018
- Soft freeze of release branch: 30 Dec 2018
- RC1: 2 Jan 2019
- Final release: 15 Jan 2019
Besides r.mapcalc.simple we have three fixes to offer, see
On Sat, Dec 29, 2018 at 4:15 PM Martin Landa <landa.martin@gmail.com> wrote:
so 29. 12. 2018 v 11:26 odesĂlatel Helmut Kudrnovsky <hellik@web.de> napsal:
> >The question is: do we need a RC cycle or can we release this time
> >straight?
>
> as time is very short, not sure if RC 1 will be tested.
>
> I'm in favour to release straight.
same here, but probably after [1]. It will take few days. Ma
On Sat, Dec 29, 2018 at 11:20 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Dec 29, 2018 at 4:15 PM Martin Landa <landa.martin@gmail.com> wrote:
> so 29. 12. 2018 v 11:26 odesĂlatel Helmut Kudrnovsky <hellik@web.de> napsal:
> > >The question is: do we need a RC cycle or can we release this time
> > >straight?
> >
> > as time is very short, not sure if RC 1 will be tested.
> >
> > I'm in favour to release straight.
>
> same here, but probably after [1]. It will take few days. Ma
>
> [1] https://trac.osgeo.org/grass/ticket/3718
May we release?
Here the changes so far:
@73871 2 days neteler i.atcorr manual: fix sat numbering @73869 2 days neteler v.vol.rst: fix user
warning as cellout is undefined here (trunk r73867) @73854 3 days neteler bulk fixing of typos
in comments (using tools/fix_typos.sh) @73845 4 days neteler avoid C++ style comments in C @73842 4 days neteler grass.py: minor
comment and msg fixes; trailing white space removed … @73839 4 days martinl wingrass: switch to
GDAL 2.4.0 in OSGeo4W (g74: merge r73833 and … @73825 7 days mmetz v.distance: improve
iterative search, fix for dmax (backport trunk r73823) @73822 8 days mmetz v.distance: speed
improvement for small dmax (backport trunk r73820) @73819 9 days mmetz v.out.ogr: fix #3714,
segfault with -n (backport trunk r73817) @73809 2 weeks hellik d.rast.edit: add
wxGUI.rdigit reference to manual @73804 2 weeks neteler r.mapcalc.simple: added from … @73795 3 weeks martinl i.segment: fix r73512
writing out segment ids (merge … @73780 3 weeks neteler r.in.wms: added missing
.tif extension needed by gdalwarp (GDAL 2.3+), … @73761 4 weeks neteler i18N: msg fixes (trunk,
r73754, r73755, r73757, r73758, r73759) @73750 4 weeks martinl grass.py: fix
inconsistent indentation @73744 4 weeks annakrat r.in.lidar man page typo
(merge from trunk, r73742) @73737 4 weeks neteler i18N: sync from Transifex … @73717 5 weeks neteler doc/howto_release.txt: minor update
On Fri, Jan 4, 2019 at 5:42 PM Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Jan 1, 2019 at 8:09 PM Markus Neteler <neteler@osgeo.org> wrote:
> On Sat, Dec 29, 2018 at 11:20 PM Markus Neteler <neteler@osgeo.org> wrote:
...
> May we release?
What is the reason to include the point release number in the path: %OSGEO4W_ROOT%\apps\grass\grass-7.4.2\lib ?
Why not
%OSGEO4W_ROOT%\apps\grass\grass-7.4*
or even
%OSGEO4W_ROOT%\apps\grass\grass7*
The objective is to update GRASS7 and QGIS would not need to be updated, QGIS could use a new GRASS7 version with bug fixes and enhancements without the need to update QGIS itself.
po 7. 1. 2019 v 21:40 odesĂlatel Markus Metz
<markus.metz.giswork@gmail.com> napsal:
What is the reason to include the point release number in the path: %OSGEO4W_ROOT%\apps\grass\grass-7.4.2\lib ?
probably inspired by possibility to install various GRASS versions in parallel.
Why not
%OSGEO4W_ROOT%\apps\grass\grass-7.4\*
or even
%OSGEO4W_ROOT%\apps\grass\grass7\*
The objective is to update GRASS7 and QGIS would not need to be updated, QGIS could use a new GRASS7 version with bug fixes and enhancements without the need to update QGIS itself.
Make sense. We could do this change probably before 7.6.0RC2. But then
this change should also affect lib names (but what about other
platforms?), eg. libgrass_7.6.dll, see related issue [1].
What is the reason to include the point release number in the path: %OSGEO4W_ROOT%\apps\grass\grass-7.4.2\lib ?
probably inspired by possibility to install various GRASS versions in parallel.
The mailing list is full of recommendations to use the latest released GRASS7 version. Devs know how to use different GRASS7 versions in parallel, but users should use the latest released GRASS7 version. This implies %OSGEO4W_ROOT%\apps\grass\grass7.
Why not
%OSGEO4W_ROOT%\apps\grass\grass-7.4*
or even
%OSGEO4W_ROOT%\apps\grass\grass7*
The objective is to update GRASS7 and QGIS would not need to be updated, QGIS could use a new GRASS7 version with bug fixes and enhancements without the need to update QGIS itself.
Make sense. We could do this change probably before 7.6.0RC2. But then
this change should also affect lib names (but what about other
platforms?), eg. libgrass_7.6.dll, see related issue [1].
Any opinions?
Considering the GRASS release history it makes sense to keep the minor version (y), but point releases (z) are only bugfix releases, no need to keep z.
