pá 14. 9. 2018 v 17:33 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
> Proposal of release: 14 Sep
> Soft freeze of release branch: 21 Sep
> RC1: 05 Oct
> RC2: 19 Oct
> Final release: 26 Oct 2018
>
> It's 4 months after 7.4.1.
>
> What do you think? Since it's point version we could shorten "Soft
> freeze of release branch" and release RC1 earlier.
Sounds good. I think that release branch is in pretty good shape, i.e.
I don't expect any backports any more.
great, I took liberty to shorten soft freeze period [1]. Ma
pá 14. 9. 2018 v 18:08 odesílatel Martin Landa <landa.martin@gmail.com> napsal:
> > RC1: 05 Oct
BTW, there is blocker [1]. Is there anyone who is planning to work on
this issue? Otherwise we would need to postpone release or decrease
ticket priority.
BTW, there is blocker [1]. Is there anyone who is planning to work on
this issue? Otherwise we would need to postpone release or decrease
ticket priority.
Time schedule:
- Proposal of release: 14 Sep [DONE]
- Soft freeze of release branch: 21 Sep [DONE]
- RC1: 28 Sep [DONE]
- RC2: 12 Oct <== I'll do that today!
- Final release: 19 Oct
ne 14. 10. 2018 v 12:42 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
- Proposal of release: 14 Sep [DONE]
- Soft freeze of release branch: 21 Sep [DONE]
- RC1: 28 Sep [DONE]
- RC2: 12 Oct <== I'll do that today!
- Final release: 19 Oct
if no objection I would suggest to trigger tagging final release.
to avoid broken GRASS plugin in OSGeo4W for longer time I just wanted
to ask you if you are rebuilding qgis osgeo4w packages automatically
when new GRASS version is published? Should I inform you about new
GRASS version personally or you are following also GRASS ML? For
better cooperation in the future: I could put new grass version to
expr (test) at first, wait for new qgis build and then publish also
grass. What do you think, Ma
---------- Forwarded message ---------
From: Martin Landa <landa.martin@gmail.com>
Date: st 24. 10. 2018 v 9:53
Subject: Re: [GRASS-dev] [release] planning GRASS 7.4.2
To: Markus Neteler <neteler@osgeo.org>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Hi,
po 22. 10. 2018 v 22:00 odesílatel Markus Neteler <neteler@osgeo.org> napsal:
> > - Final release: 19 Oct
>
> if no objection I would suggest to trigger tagging final release.
wingrass packages (osgeo4w and standalone) uploaded. UbuntuGIS
packages will be packaged in the next days. Ma
st 28. 11. 2018 v 14:28 odesílatel Jürgen E. Fischer <jef@norbit.de> napsal:
I updated the processing provider to automatically pick the latest GRASS
directory - before it was configured in the user profile and never updated at
all and processing would look broken after a GRASS update - that should be fine
now.
thanks for info.
But the GRASS plugin will be broken between the GRASS update and the next QGIS
point release. As QGIS will only be built automatically on QGIS releases.
This is very unfortunate (cc'ed to grass-dev). We have two options:
1) update GRASS package (as current) to OSGeo4W when released
+ a new GRASS version available in OSGeo4W when released
- we don't care about broken QGIS GRASS plugin
2) publish GRASS release in OSGeo4W as test package and change to
current when new QGIS point release
+ QGIS GRASS plugin will be not broken
- new GRASS version available when QGIS point release published
+/- there is still possibility to install new GRASS version from Expr area
Any comments? I would vote for 2). In this case Juergen could you
change test -> curr in GRASS setup.hint when pushing new QGIS point
release to OSGeo4W or let me/us know to do it? Would be nice to
collaborate more closely to avoid broken QGIS-GRASS interfaces.
On Wed, 28. Nov 2018 at 14:39:16 +0100, Martin Landa wrote:
1) update GRASS package (as current) to OSGeo4W when released
+ a new GRASS version available in OSGeo4W when released
- we don't care about broken QGIS GRASS plugin
2) publish GRASS release in OSGeo4W as test package and change to
current when new QGIS point release
+ QGIS GRASS plugin will be not broken
- new GRASS version available when QGIS point release published
+/- there is still possibility to install new GRASS version from Expr area
Any comments? I would vote for 2). In this case Juergen could you
change test -> curr in GRASS setup.hint when pushing new QGIS point
release to OSGeo4W or let me/us know to do it? Would be nice to
collaborate more closely to avoid broken QGIS-GRASS interfaces.
Last time the GRASS release was shortly before the QGIS release and fell in
smoothly - this time it's shortly after. The QGIS release echedule is set long
upfront.
Not putting the patch level into the GRASS library names (and keeping an eye on
the ABI - but I suppose the library interfaces only change rarely anyway - and
if so not on point releases), would be a third option. IIRC there's also still
a safety check to remove in the GRASS libs to make this possible. Then GRASS
point releases wouldn't need a QGIS rebuild at all.
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
On Wed, 28. Nov 2018 at 14:39:16 +0100, Martin Landa wrote:
1) update GRASS package (as current) to OSGeo4W when released
+ a new GRASS version available in OSGeo4W when released
- we don't care about broken QGIS GRASS plugin
2) publish GRASS release in OSGeo4W as test package and change to
current when new QGIS point release
+ QGIS GRASS plugin will be not broken
- new GRASS version available when QGIS point release published
+/- there is still possibility to install new GRASS version from Expr area
Any comments? I would vote for 2). In this case Juergen could you
change test -> curr in GRASS setup.hint when pushing new QGIS point
release to OSGeo4W or let me/us know to do it? Would be nice to
collaborate more closely to avoid broken QGIS-GRASS interfaces.
Last time the GRASS release was shortly before the QGIS release and fell in
smoothly - this time it's shortly after. The QGIS release echedule is set long
upfront.
Not putting the patch level into the GRASS library names (and keeping an eye on
the ABI - but I suppose the library interfaces only change rarely anyway - and
if so not on point releases), would be a third option. IIRC there's also still
a safety check to remove in the GRASS libs to make this possible. Then GRASS
point releases wouldn't need a QGIS rebuild at all.
This sounds like the way to go for me. AFAIK, there shouldn't be ABI changes between point releases.
st 28. 11. 2018 v 15:08 odesílatel Moritz Lennert
<mlennert@club.worldonline.be> napsal:
> Not putting the patch level into the GRASS library names (and keeping an eye on
> the ABI - but I suppose the library interfaces only change rarely anyway - and
> if so not on point releases), would be a third option. IIRC there's also still
> a safety check to remove in the GRASS libs to make this possible. Then GRASS
> point releases wouldn't need a QGIS rebuild at all.
I changed trunk to produce also unversioned libs similarly as on
non-mingw platforms [0]. On Windows it's simply copy of versioned
libs. Is it acceptable solution? If so I will do backport to g76 a g74
branches ASAP. BTW, GRASS 7.4.4 is planned to be released in next
days, see [1].