Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Alessandro Pasotti]

On Thu, Nov 28, 2019 at 5:16 PM Jürgen E. Fischer  wrote:

> Hi,
>
> On Thu, 28. Nov 2019 at 10:56:01 +0100, Jürgen E. Fischer wrote:
> > Anyway, introducing proj5 and gdal2 packages could work - but not without
> > shifting the point release date again.
>
> As nobody objected (or read that far ;)) I have taken the liberty of
> moving the
> point releases for another week - which is hopefully enough to sort this
> out.
>
>
Sounds a wise decision given the amount of issues that continue to drop
into the bug tracker.

Cheers

just to prove that someone reads your messages when they are short enough ;)

-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Tim Sutton]

Hi

> On 28 Nov 2019, at 10:05, Matthias Kuhn  wrote:
>> 
>> 
>> As soon as we have a clear view on the strategy, I think we MUST communicate 
>> widely. We can also ask for support for this, though it will not be an easy 
>> message.  
> I agree, this would be perfectly served in a post including all the 
> advantages of proj6 which have been widely distributed on tech channels, but 
> went by unnoticed by a large audience. Spreading the word about this bundled 
> with the effects on the gis ecosystem would make a very good news.
> 

Perfect use case for our feed!

For my part I would like to release 3.4.14 with the same binary footprint as 
3.4.12 had, but bump the version number in the app so it appears as 3.4.14. 
Then stop any more releases for 3.4. If Jürgen is willing and QGIS.org 
 can fund this I think it would be a very good way forward.

Regards

Tim

> Regards
> 
> Matthias
> 
>> 
>> Cheers
>> Régis
>> 
>>  
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi,

On Thu, 28. Nov 2019 at 10:56:01 +0100, Jürgen E. Fischer wrote:
> Anyway, introducing proj5 and gdal2 packages could work - but not without
> shifting the point release date again.

As nobody objected (or read that far ;)) I have taken the liberty of moving the
point releases for another week - which is hopefully enough to sort this out.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Paolo Cavallini]

Hi Even

Il 28/11/19 15:48, Even Rouault ha scritto:
> Jürgen,
> 
>> I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
>> azure-pipelines (which kind of works) and github workflows (which does not
>> yet work) to implement the Windows CI many people are keen on.  Progress is
>> very slow - every single step takes ages…   A successful run takes more
>> than 2-3h on azure-pipelines…
> 
> Did you try to contact azure-pipeline support ? They might be receptive to a 
> request to increase both the CPU count and disk space. Especially if you say 
> that QGIS is a cool open source project where people can display... Bing Maps 
> !

I did, I''l update the list in case of a positive reply.
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Even,

On Thu, 28. Nov 2019 at 15:48:42 +0100, Even Rouault wrote:
> > I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
> > azure-pipelines (which kind of works) and github workflows (which does not
> > yet work) to implement the Windows CI many people are keen on.  Progress is
> > very slow - every single step takes ages…   A successful run takes more
> > than 2-3h on azure-pipelines…
 
> Did you try to contact azure-pipeline support ? They might be receptive to a
> request to increase both the CPU count and disk space. Especially if you say
> that QGIS is a cool open source project where people can display... Bing Maps
> !

You think?  I didn't try that yet - but I apparently didn't yet fully grasp the
cache concept - I only perchance had a few hits - but the misses might well be,
because I meanwhile changed either the key or they weren't written in the first
place because the available space was already exceeded.  A list of caches to
check would be nice…


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

Jürgen,

> I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
> azure-pipelines (which kind of works) and github workflows (which does not
> yet work) to implement the Windows CI many people are keen on.  Progress is
> very slow - every single step takes ages…   A successful run takes more
> than 2-3h on azure-pipelines…

Did you try to contact azure-pipeline support ? They might be receptive to a 
request to increase both the CPU count and disk space. Especially if you say 
that QGIS is a cool open source project where people can display... Bing Maps 
!

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Sandro Santilli]

On Thu, Nov 28, 2019 at 10:56:01AM +0100, Jürgen E. Fischer wrote:

> I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
> azure-pipelines (which kind of works) and github workflows (which does not yet
> work) to implement the Windows CI many people are keen on. 

If you want to try yet another one:
https://blog.drone.io/drone-cloud-native-ci-cd-windows-containers/

I didn't go trough all the description (as I'm kind of allergic to
Windows) but "Drone" itself is OpenSource so anything you learn in
the excercise would be reusable.

Also OSGeo infra has a running Drone server so QGIS might be plugging
in a windows "agent" with arbitrary resources to deal with the timeout.

--strk;
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Mathieu Pellerin]

Ouch! ;) yes, 2020.

On Thu, Nov 28, 2019, 16:57 Jürgen E. Fischer  wrote:

> Hi Mathieu,
>
> On Thu, 28. Nov 2019 at 15:36:39 +0700, Mathieu Pellerin wrote:
> > For the record, according to schedule, 3.4 reaches its end of life on
> > February 21st, 2010.
>
> 2020?
>
> 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
> https://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Matthias Kuhn]

Hi Jürgen

On 11/28/19 10:59 AM, Jürgen E. Fischer wrote:

Hi Matthias,

On Thu, 28. Nov 2019 at 10:05:53 +0100, Matthias Kuhn wrote:

Originally I wasn't even thinking about an OSGeo4W installer, I was simply
hoping for standalone installers. But if OSGeo4W double-packaging is
feasible, that would be the cherry on top.

The standalone is always just a snapshot of osgeo4w.


I was hoping that building a standalone from a local snapshot would be 
easier than having to make sure this is actually available in the main 
or a duplicate repo.


Matthias

  


Jürgen


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Matthias,

On Thu, 28. Nov 2019 at 10:05:53 +0100, Matthias Kuhn wrote:
> Originally I wasn't even thinking about an OSGeo4W installer, I was simply
> hoping for standalone installers. But if OSGeo4W double-packaging is
> feasible, that would be the cherry on top.

The standalone is always just a snapshot of osgeo4w.
 

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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Mathieu,

On Thu, 28. Nov 2019 at 15:36:39 +0700, Mathieu Pellerin wrote:
> For the record, according to schedule, 3.4 reaches its end of life on
> February 21st, 2010.

2020?

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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Andreas,

On Thu, 28. Nov 2019 at 09:11:07 +0100, Andreas Neumann wrote:
> Thanks all for the discussion.
 
> I would like to hear Jürgen's opinion on it was well. If possible, I would
> also prefer Matthias approach. Our organization just recently introduced 3.4
> LTR (I know we are late ;-), we will probably move to 3.10 in mid 2020). It
> would be nice if the support of the 3.4 release could be a bit longer, until
> 3.10 takes over as LTR version.
 
> QGIS.ORG can fund Jürgen for this extra work for supporting two library
> versions in parallel, if Jürgen thinks this can be done with a reasonable
> amount of work (whatever this means ;-) )

I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
azure-pipelines (which kind of works) and github workflows (which does not yet
work) to implement the Windows CI many people are keen on.  Progress is very
slow - every single step takes ages…   A successful run takes more than 2-3h on
azure-pipelines…   Caching would help, but hits disk space limits.  github
workflows currently needs 0.5h to hit the first obstacle (ie. first compiler
invocation).

I could probably have done "fix windows build" commits of a life time with less
effort ;)

Anyway, introducing proj5 and gdal2 packages could work - but not without
shifting the point release date again.

And that's only considering QGIS.  GRASS and spatialite are now using PROJ 6
too.  Not sure if that can be made to work together as is or whether we'd need
separate packages for those too.

Duplicating the osgeo4w repositories for this and rolling the fork back to the
previous state could be an option too - the old packages are still there - but
that would break the packaging routines.   People using the osgeo4w installer
would also need to change the URL to get it.   So that's not very appealing
either.



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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Matthias Kuhn]

Thanks for all the comments on this

On 11/28/19 9:50 AM, Régis Haubourg wrote:


Hi all,
Le jeu. 28 nov. 2019 à 09:02, Matthias Kuhn > a écrit :


[..]

With LTR we have built a brand with a very good reputation and I
think we should protect this label and avoid any controversial
communication if reasonably possible.

[..]

Matthias


Well, I really second Matthias's point of view here.
This may weaken our message about LTR long term support. Many 
corporations are *just* migrating to it now and we have hard time 
convincing them to stick with LTR versions so that they can fund and 
benefit of fixes during the LTR lifespan. I'm afraid that freezing it 
now will upset some of them.


If the options of building a dedicated OSGEO4W installer with old GDAL 
and proj is feasable, I am really really +1 on this.


Originally I wasn't even thinking about an OSGeo4W installer, I was 
simply hoping for standalone installers. But if OSGeo4W double-packaging 
is feasible, that would be the cherry on top.




Anyway, it is a major change and I totally understand the situation. 
Many thanks again for digging into constructive solutions.
If we explain largely the benefits of PROJ6, I am confident most users 
will understand the move, and a 3 months wait is not a long wait for 
fixes.


As soon as we have a clear view on the strategy, I think we MUST 
communicate widely. We can also ask for support for this, though it 
will not be an easy message.


I agree, this would be perfectly served in a post including all the 
advantages of proj6 which have been widely distributed on tech channels, 
but went by unnoticed by a large audience. Spreading the word about this 
bundled with the effects on the gis ecosystem would make a very good news.


Regards

Matthias



Cheers
Régis

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Mathieu Pellerin]

For the record, according to schedule, 3.4 reaches its end of life on
February 21st, 2010.



On Thu, Nov 28, 2019, 15:11 Andreas Neumann  wrote:

> Hi all,
>
> Thanks all for the discussion.
>
> I would like to hear Jürgen's opinion on it was well. If possible, I would
> also prefer Matthias approach. Our organization just recently introduced
> 3.4 LTR (I know we are late ;-), we will probably move to 3.10 in mid
> 2020). It would be nice if the support of the 3.4 release could be a bit
> longer, until 3.10 takes over as LTR version.
>
> QGIS.ORG can fund Jürgen for this extra work for supporting two library
> versions in parallel, if Jürgen thinks this can be done with a reasonable
> amount of work (whatever this means ;-) )
>
> Thanks,
>
> Andreas
>
> On 2019-11-28 09:02, Matthias Kuhn wrote:
>
> Hi all,
>
> I enjoy reading the discussion on this tricky topic. Thank you for looking
> into this!
>
> What would be the precise plan of action?
>
> The situation is, a new QGIS 3.4.13 release based on gdal3/proj6 is out
> already. We cannot make that undone unless we get out the message to forget
> that 3.4.13 ever existed and ask everyone to reinstall 3.4.12.
>
> I wonder if it wouldn't be easier to setup a system somewhere to build
> with the old gdal and proj libraries to create the remaining standalone
> installers to push out the remaining three 3.4 releases (manually). With
> LTR we have built a brand with a very good reputation and I think we should
> protect this label and avoid any controversial communication if reasonably
> possible.
>
> It's possible that I am underestimating the work which would be required
> to do this, but in my opinion this would be a good opportunity to do an
> ad-hoc investment into Jürgen (given that he has some of his precious time
> left to actually work on this and that he does not completely disagree with
> me).
>
> Best regards
>
> Matthias
> On 11/28/19 1:47 AM, Nathan Woodrow wrote:
>
> Just have to make sure we communicate this via the blog and why.
>
> On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin 
> wrote:
>
> +1 to end 3.4 cycle a few months early too.
>
> On Thu, Nov 28, 2019, 05:57 Nathan Woodrow  wrote:
>
> +1 on dropping support early as the risk is large on breaking the users
> experience with a LTR
>
> On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
> wrote:
>
> > I think the issues are deeper then the crashes/projection failures
> > fixed by the GDAL/proj cherry-picked commits.
>
> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it
> uses the old pj_transform() API with doesn't trigger that code path at
> all.
> But it *is* affected by exportToProj4() no longer returning +datum or
> +towgs84
> in cases where it used to be, which basically makes working with anything
> !=
> WGS 84 fundamentaly broken. The only "fix" would be to backport the fully
> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in 3.4
>
> > think we SHOULD drop
> > Windows LTR support early rather than releasing a 3.4 build based on
> > proj6/gdal3.
>
> +1
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Paolo Cavallini]

Hi all,
I agree, very fruitful discussion. Also agree: it is the release manager
who has the last word on this.
AFAICT we have two options:
* reverting to .12, and stop releasing new versions
* replacing .13 to gdal2+proj4, and keep on releasing with the standard
schedule.
I believe the main factor is how much we want to push towards 3.10: if
we feel it has really important new features, and is generally very
stable, this would make the first option more attractive. If not, then
investing on 3.4, and possibly support it for a longer period to justify
the extra investment, would make sense.
All best wishes.

Il 28/11/19 09:11, Andreas Neumann ha scritto:
> Hi all,
> 
> Thanks all for the discussion.
> 
> I would like to hear Jürgen's opinion on it was well. If possible, I
> would also prefer Matthias approach. Our organization just recently
> introduced 3.4 LTR (I know we are late ;-), we will probably move to
> 3.10 in mid 2020). It would be nice if the support of the 3.4 release
> could be a bit longer, until 3.10 takes over as LTR version.
> 
> QGIS.ORG can fund Jürgen for this extra work for supporting two library
> versions in parallel, if Jürgen thinks this can be done with a
> reasonable amount of work (whatever this means ;-) )
> 
> Thanks,
> 
> Andreas
> 
> On 2019-11-28 09:02, Matthias Kuhn wrote:
> 
>> Hi all,
>>
>> I enjoy reading the discussion on this tricky topic. Thank you for
>> looking into this!
>>
>> What would be the precise plan of action?
>>
>> The situation is, a new QGIS 3.4.13 release based on gdal3/proj6 is
>> out already. We cannot make that undone unless we get out the message
>> to forget that 3.4.13 ever existed and ask everyone to reinstall 3.4.12.
>>
>> I wonder if it wouldn't be easier to setup a system somewhere to build
>> with the old gdal and proj libraries to create the remaining
>> standalone installers to push out the remaining three 3.4 releases
>> (manually). With LTR we have built a brand with a very good reputation
>> and I think we should protect this label and avoid any controversial
>> communication if reasonably possible.
>>
>> It's possible that I am underestimating the work which would be
>> required to do this, but in my opinion this would be a good
>> opportunity to do an ad-hoc investment into Jürgen (given that he has
>> some of his precious time left to actually work on this and that he
>> does not completely disagree with me).
>>
>> Best regards
>>
>> Matthias
>>
>> On 11/28/19 1:47 AM, Nathan Woodrow wrote:
>>> Just have to make sure we communicate this via the blog and why.
>>>
>>> On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin
>>> mailto:nirvn.a...@gmail.com>> wrote:
>>>
>>> +1 to end 3.4 cycle a few months early too. 
>>>
>>> On Thu, Nov 28, 2019, 05:57 Nathan Woodrow >> > wrote:
>>>
>>> +1 on dropping support early as the risk is large on breaking
>>> the users experience with a LTR
>>>
>>> On Thu., 28 Nov. 2019, 8:55 am Even Rouault,
>>> >> > wrote:
>>>
>>> > I think the issues are deeper then the
>>> crashes/projection failures
>>> > fixed by the GDAL/proj cherry-picked commits.
>>>
>>> Yes, actually QGIS 3.4 should not be affected by the PROJ
>>> fix, because it 
>>> uses the old pj_transform() API with doesn't trigger that
>>> code path at all.
>>> But it *is* affected by exportToProj4() no longer
>>> returning +datum or +towgs84
>>> in cases where it used to be, which basically makes
>>> working with anything !=
>>> WGS 84 fundamentaly broken. The only "fix" would be to
>>> backport the fully
>>> fledged PROJ 6 support of 3.10 which is obviously
>>> unreasonable to do in 3.4
>>>
>>> > think we SHOULD drop
>>> > Windows LTR support early rather than releasing a 3.4
>>> build based on
>>> > proj6/gdal3.
>>>
>>> +1
>>>
>>> -- 
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> 
>>> List info:
>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe:
>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> 
>>> List info:
>>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe:
>>> 

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Andreas Neumann]

Hi all, 

Thanks all for the discussion. 


I would like to hear Jürgen's opinion on it was well. If possible, I
would also prefer Matthias approach. Our organization just recently
introduced 3.4 LTR (I know we are late ;-), we will probably move to
3.10 in mid 2020). It would be nice if the support of the 3.4 release
could be a bit longer, until 3.10 takes over as LTR version. 


QGIS.ORG can fund Jürgen for this extra work for supporting two library
versions in parallel, if Jürgen thinks this can be done with a
reasonable amount of work (whatever this means ;-) ) 

Thanks, 

Andreas 


On 2019-11-28 09:02, Matthias Kuhn wrote:

Hi all, 

I enjoy reading the discussion on this tricky topic. Thank you for looking into this! 

What would be the precise plan of action? 

The situation is, a new QGIS 3.4.13 release based on gdal3/proj6 is out already. We cannot make that undone unless we get out the message to forget that 3.4.13 ever existed and ask everyone to reinstall 3.4.12. 

I wonder if it wouldn't be easier to setup a system somewhere to build with the old gdal and proj libraries to create the remaining standalone installers to push out the remaining three 3.4 releases (manually). With LTR we have built a brand with a very good reputation and I think we should protect this label and avoid any controversial communication if reasonably possible. 

It's possible that I am underestimating the work which would be required to do this, but in my opinion this would be a good opportunity to do an ad-hoc investment into Jürgen (given that he has some of his precious time left to actually work on this and that he does not completely disagree with me). 

Best regards 


Matthias

On 11/28/19 1:47 AM, Nathan Woodrow wrote: 
Just have to make sure we communicate this via the blog and why. 

On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin  wrote: 

+1 to end 3.4 cycle a few months early too. 

On Thu, Nov 28, 2019, 05:57 Nathan Woodrow  wrote: 
+1 on dropping support early as the risk is large on breaking the users experience with a LTR 


On Thu., 28 Nov. 2019, 8:55 am Even Rouault,  wrote: 
> I think the issues are deeper then the crashes/projection failures

fixed by the GDAL/proj cherry-picked commits.


Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it  
uses the old pj_transform() API with doesn't trigger that code path at all. 
But it *is* affected by exportToProj4() no longer returning +datum or +towgs84 
in cases where it used to be, which basically makes working with anything != 
WGS 84 fundamentaly broken. The only "fix" would be to backport the fully 
fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in 3.4



think we SHOULD drop
Windows LTR support early rather than releasing a 3.4 build based on
proj6/gdal3.


+1

--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Matthias Kuhn]

Hi all,

I enjoy reading the discussion on this tricky topic. Thank you for 
looking into this!


What would be the precise plan of action?

The situation is, a new QGIS 3.4.13 release based on gdal3/proj6 is out 
already. We cannot make that undone unless we get out the message to 
forget that 3.4.13 ever existed and ask everyone to reinstall 3.4.12.


I wonder if it wouldn't be easier to setup a system somewhere to build 
with the old gdal and proj libraries to create the remaining standalone 
installers to push out the remaining three 3.4 releases (manually). With 
LTR we have built a brand with a very good reputation and I think we 
should protect this label and avoid any controversial communication if 
reasonably possible.


It's possible that I am underestimating the work which would be required 
to do this, but in my opinion this would be a good opportunity to do an 
ad-hoc investment into Jürgen (given that he has some of his precious 
time left to actually work on this and that he does not completely 
disagree with me).


Best regards

Matthias

On 11/28/19 1:47 AM, Nathan Woodrow wrote:

Just have to make sure we communicate this via the blog and why.

On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin 
mailto:nirvn.a...@gmail.com>> wrote:


+1 to end 3.4 cycle a few months early too.

On Thu, Nov 28, 2019, 05:57 Nathan Woodrow mailto:madman...@gmail.com>> wrote:

+1 on dropping support early as the risk is large on breaking
the users experience with a LTR

On Thu., 28 Nov. 2019, 8:55 am Even Rouault,
mailto:even.roua...@spatialys.com>> wrote:

> I think the issues are deeper then the
crashes/projection failures
> fixed by the GDAL/proj cherry-picked commits.

Yes, actually QGIS 3.4 should not be affected by the PROJ
fix, because it
uses the old pj_transform() API with doesn't trigger that
code path at all.
But it *is* affected by exportToProj4() no longer
returning +datum or +towgs84
in cases where it used to be, which basically makes
working with anything !=
WGS 84 fundamentaly broken. The only "fix" would be to
backport the fully
fledged PROJ 6 support of 3.10 which is obviously
unreasonable to do in 3.4

> think we SHOULD drop
> Windows LTR support early rather than releasing a 3.4
build based on
> proj6/gdal3.

+1

-- 
Spatialys - Geospatial professional services

http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org

List info:
https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:
https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org

List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:
https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

Just have to make sure we communicate this via the blog and why.

On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin 
wrote:

> +1 to end 3.4 cycle a few months early too.
>
> On Thu, Nov 28, 2019, 05:57 Nathan Woodrow  wrote:
>
>> +1 on dropping support early as the risk is large on breaking the users
>> experience with a LTR
>>
>> On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
>> wrote:
>>
>>> > I think the issues are deeper then the crashes/projection failures
>>> > fixed by the GDAL/proj cherry-picked commits.
>>>
>>> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because
>>> it
>>> uses the old pj_transform() API with doesn't trigger that code path at
>>> all.
>>> But it *is* affected by exportToProj4() no longer returning +datum or
>>> +towgs84
>>> in cases where it used to be, which basically makes working with
>>> anything !=
>>> WGS 84 fundamentaly broken. The only "fix" would be to backport the
>>> fully
>>> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in
>>> 3.4
>>>
>>> > think we SHOULD drop
>>> > Windows LTR support early rather than releasing a 3.4 build based on
>>> > proj6/gdal3.
>>>
>>> +1
>>>
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Mathieu Pellerin]

+1 to end 3.4 cycle a few months early too.

On Thu, Nov 28, 2019, 05:57 Nathan Woodrow  wrote:

> +1 on dropping support early as the risk is large on breaking the users
> experience with a LTR
>
> On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
> wrote:
>
>> > I think the issues are deeper then the crashes/projection failures
>> > fixed by the GDAL/proj cherry-picked commits.
>>
>> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because
>> it
>> uses the old pj_transform() API with doesn't trigger that code path at
>> all.
>> But it *is* affected by exportToProj4() no longer returning +datum or
>> +towgs84
>> in cases where it used to be, which basically makes working with anything
>> !=
>> WGS 84 fundamentaly broken. The only "fix" would be to backport the fully
>> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in
>> 3.4
>>
>> > think we SHOULD drop
>> > Windows LTR support early rather than releasing a 3.4 build based on
>> > proj6/gdal3.
>>
>> +1
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

+1 on dropping support early as the risk is large on breaking the users
experience with a LTR

On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
wrote:

> > I think the issues are deeper then the crashes/projection failures
> > fixed by the GDAL/proj cherry-picked commits.
>
> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it
> uses the old pj_transform() API with doesn't trigger that code path at
> all.
> But it *is* affected by exportToProj4() no longer returning +datum or
> +towgs84
> in cases where it used to be, which basically makes working with anything
> !=
> WGS 84 fundamentaly broken. The only "fix" would be to backport the fully
> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in 3.4
>
> > think we SHOULD drop
> > Windows LTR support early rather than releasing a 3.4 build based on
> > proj6/gdal3.
>
> +1
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

> I think the issues are deeper then the crashes/projection failures
> fixed by the GDAL/proj cherry-picked commits.

Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it  
uses the old pj_transform() API with doesn't trigger that code path at all. 
But it *is* affected by exportToProj4() no longer returning +datum or +towgs84 
in cases where it used to be, which basically makes working with anything != 
WGS 84 fundamentaly broken. The only "fix" would be to backport the fully 
fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in 3.4

> think we SHOULD drop
> Windows LTR support early rather than releasing a 3.4 build based on
> proj6/gdal3.

+1

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nyall Dawson]

On Wed, 27 Nov 2019 at 18:37, Jürgen E. Fischer  wrote:
>
> Hi Andrea,
>
> On Wed, 27. Nov 2019 at 00:59:08 -0700, andreaerdna wrote:
> > What about the OSGeo4W installer? Now, installing qgis-ltr from OSGeo4W
> > installer will also install gdal-3.0.2-3 and proj-6.2.1-2.
>
> And those don't fix the issue for you?

I think the issues are deeper then the crashes/projection failures
fixed by the GDAL/proj cherry-picked commits.

The work I did a couple of months back allowing QGIS 3.4 to be built
with gdal 3 (https://github.com/qgis/QGIS/pull/30072) was really just
a very thin band-aid, designed as a worst case scenario to permit
mostly working build to proceed in the case that a distro ONLY has
gdal 3 available.

From that pr conversation -- a retrospectively (very) naive comment I
made relating to this:

"The reality is that we won't always be able to dictate the library
versions for 3.4. We can for osgeo4w, because we (well, @jef-n)
controls that infrastructure, but there's many other platforms where
we have no say in this. Including a bunch of wild-west ecosystems
where people upgrade stuff just to see what other stuff they can
break (*cough* homebrew *cough*). We've still got at least 6
months left to support 3.4, so sooner or later we'll need to make it
usable on the newer libraries, even if that means a bunch of
short-term hacks and workarounds to make it work with this. The only
other option is dropping the LTR support early, but I don't think
that's possible/a good idea."

I've changed my mind since this comment, and now think we SHOULD drop
Windows LTR support early rather than releasing a 3.4 build based on
proj6/gdal3.

Nyall


>
> 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 Nordenhttps://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Andrea,

On Wed, 27. Nov 2019 at 00:59:08 -0700, andreaerdna wrote:
> What about the OSGeo4W installer? Now, installing qgis-ltr from OSGeo4W
> installer will also install gdal-3.0.2-3 and proj-6.2.1-2.

And those don't fix the issue for you?

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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[andreaerdna]

Nyall Dawson wrote
> So we could revert to 3.4.13-1

It seems the standalone installer 3.4.13-2 for MS Windows is still available
for download on qgis.org.

Would it be possible to undo the commit
https://github.com/qgis/QGIS-Website/commit/6a9c3a01b98a291be21994dd61d8c0299b9a7ead
?

Undoing the commit will also revert the latest release standalone installer
downloadable to 3.10.0-1 (based on GDAL 2.4.1 and PROJ 5.2.0) instead of the
current 3.10.0-2 (GDAL 3.0.2 + PROJ 6.2.1), waiting for the new 3.10.1 that
will fix the crs problems.

What about the OSGeo4W installer? Now, installing qgis-ltr from OSGeo4W
installer will also install gdal-3.0.2-3 and proj-6.2.1-2.

Best regards.

Andrea Giudiceandrea



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nyall Dawson]

> An alternative would be to keep on
> releasing new versions, issuing a big warning about the risks and
> complications involved, so as to leave the responsibility in the hands
> of users.

I may be skeptical and underestimate our users, but I honestly
wouldn't feel comfortable placing this choice into users hands. I just
don't think an end-user would be able to grasp the full complexities
of the situation here and the possible repercussions.

> - QGIS-OSGeo4W-3.4.13-1
> both with GDAL 2.4.1 + PROJ 5.2.0 (+ proj4dll 4.9.3)
>
> and
> - QGIS-OSGeo4W-3.4.13-2
> with GDAL 3.0.2 + PROJ 6.2.1

> You are right.

So we could revert to 3.4.13-1 and leave that as the final 3.4 windows release?

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Andrea,

On Sun, 24. Nov 2019 at 09:24:36 -0700, andreaerdna wrote:
> Even Rouault-2 wrote
> > That would rather be 3.4.12 to have the last built based on GDAL 2.4 +
> > PROJ 5, 
> > no ? At least for the standalone installer

> If I'm not wrong, there are:
 
> - QGIS-OSGeo4W-3.4.12-1
> - QGIS-OSGeo4W-3.4.13-1
> both with GDAL 2.4.1 + PROJ 5.2.0 (+ proj4dll 4.9.3)
> 
> and
> - QGIS-OSGeo4W-3.4.13-2
> with GDAL 3.0.2 + PROJ 6.2.1

You are right.



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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[andreaerdna]

Even Rouault-2 wrote
> That would rather be 3.4.12 to have the last built based on GDAL 2.4 +
> PROJ 5, 
> no ? At least for the standalone installer

If I'm not wrong, there are:

- QGIS-OSGeo4W-3.4.12-1
- QGIS-OSGeo4W-3.4.13-1
both with GDAL 2.4.1 + PROJ 5.2.0 (+ proj4dll 4.9.3)

and
- QGIS-OSGeo4W-3.4.13-2
with GDAL 3.0.2 + PROJ 6.2.1

Best regards.

Andrea



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

> I'd also like to extend Tim's thanks here and publicly state my
> appreciation to Jürgen for an extremely difficult, thankless job which
> you've done SO well, SO consistently and for SO long.

I "third" this appreciation !

> Regarding 3.4: One option we should explore is just freezing the
> Windows releases at 3.4.13

That would rather be 3.4.12 to have the last built based on GDAL 2.4 + PROJ 5, 
no ? At least for the standalone installer

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Paolo Cavallini]

Hi Nyall, all

Il 2019-11-24 05:13 Nyall Dawson ha scritto:

Regarding 3.4: One option we should explore is just freezing the
Windows releases at 3.4.13, and leaving 3.4.13 as the final supported
3.4 release for Windows. (For reference, 3.4.16 is the planned final
3.4.x release, so we'd "lose" 3 months of supported new releases). I'd
personally be +1 to this, given that the existing infrastructure
cannot be easily modified to allow a proj4 based build, and adding
this support is far from trivial. While it's not ideal, I think
finalizing the Windows releases at 3.4.13 is much less risk and better
for our users then risking projection handling issues. (For full
disclosure of information I've included a list of fixes as [1] which
are included in 3.4.14 at the time of writing which would NOT be
available for Windows users as a result)


This is what I suggested, that's why I asked whether there are very 
important bugfixes until now. An alternative would be to keep on 
releasing new versions, issuing a big warning about the risks and 
complications involved, so as to leave the responsibility in the hands 
of users.

Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Tim Sutton]

Hi

Also Jürgen and Nyall: is there anything the PSC could be funding to help you 
allocate the time needed to help get things to a good conclusion? PSC this is 
IMHO be a better use of overflow funds right now than e.g. windows CI 
infrastructure.

Regards

Tim

> On 24 Nov 2019, at 04:13, Nyall Dawson  wrote:
> 
> On Sun, 24 Nov 2019 at 02:38, Jürgen E. Fischer  wrote:
> 
> 
>>> So overall how the situation was handled doesn't seem that bad for a release
>>> exercising new major dependencies.
> 
> Agreed.
> 
> I'd also like to extend Tim's thanks here and publicly state my
> appreciation to Jürgen for an extremely difficult, thankless job which
> you've done SO well, SO consistently and for SO long.
> 
> (And also +1 to whoever said that this was **always** going to be a
> very tricky transition for the opensource geo world.It's a good thing,
> but thanks to proj6 the entire software stack has been *forced* to
> mature and adapt to modern, accurate projection handling and it's
> causing/caused pain all round. At least we're mostly through the worst
> now and it's now the users and geospatial analysts who are being
> forced to mature and skill up as a consequence! And all those "data
> scientists" who blundered around thinking spatial was just numeric x/y
> coordinates have an even worse learning curve inbound...!)
> 
> Moving forward, I'm thinking/wondering:
> 
> Regarding 3.10.1: there's been some work in GDAL and PROJ which may
> help resolve the issue which triggered this discussion. I'll test
> tomorrow. I also think there's potential hacky workaround we could
> implement if we avoid re-using existing PROJ context objects in
> certain places (albeit with a performance hit as a result), which I'm
> going to explore tomorrow as a band-aid so that we can unblock the
> release.
> 
> Regarding 3.4: One option we should explore is just freezing the
> Windows releases at 3.4.13, and leaving 3.4.13 as the final supported
> 3.4 release for Windows. (For reference, 3.4.16 is the planned final
> 3.4.x release, so we'd "lose" 3 months of supported new releases). I'd
> personally be +1 to this, given that the existing infrastructure
> cannot be easily modified to allow a proj4 based build, and adding
> this support is far from trivial. While it's not ideal, I think
> finalizing the Windows releases at 3.4.13 is much less risk and better
> for our users then risking projection handling issues. (For full
> disclosure of information I've included a list of fixes as [1] which
> are included in 3.4.14 at the time of writing which would NOT be
> available for Windows users as a result)
> 
> 
> Nyall
> 
> [1]
> QgsVectorFileWriter: fix axis order issue with GDAL 3 (fixes #33014)
> Merge pull request #33003 from rldhont/backport-32800-to-release-3_4
> Fix broken QMap finding, which causes
> case-insensitive comparisons to be made when resolving primary keys in
> the Oracle and Postgres providers
> [Server] Update WMS GetProjectSettings tests for round extent in 
> GetCapabilities
> [Server] Test WCS Access Control: update comment
> [Server] Update WCS tests for round extent in GetCapabilities
> [Server] Update WMS tests for round extent in GetCapabilities
> [Server] Update WFS tests for round extent in GetCapabilities
> [Server] Update WMTS tests for round extent in GetCapabilities
> [Server] tests: Add masks
> [Bugfix][Server] Use floor and ceil for round extent coordinates in
> services capabilities
> [Bugfix][Server] Correctly round extent coordinates in services capabilities
> Wrong label in UI for "Create point for each part" on "Centroids"
> processing algorithm #32940 - Backport to 3.4
> debian packaging: python-gdal still needed for gdal python scripts
> Merge pull request #32749 from qgis/backport-32743-to-release-3_4
> database style manager: translatable & title case
> custom widgets: fix designer crash (fixes #32860)
> debian packaging: drop python-gdal dependency (closes #32835) [ci skip]
> qgsfunction: replace deprecated inspect.getargspec() to 
> inspect.getfullargspec()
> oracle provider: log when ROWID is used for a missing primary key
> (closes #32648)
> also track newer CIFS
> translation string fix
> Merge pull request #32460 from alexbruy/backport-32455-to-release-3_4
> osgeo4w: fix nightlies (followup 766149b1b6)
> In case it is needed: Update Rasterize.py for 3.4 (backport of master commit)
> Update CreateConstantRaster.py
> Merge pull request #32793 from
> rldhont/fix-server-wfs-add-primary-keys-to-request-for-fid-34
> osgeo4w: build with proj 6 and gdal 3
> Fix const
> [Bugfix][Server] WFS: Add primary keys to request to build Server Feature Id
> Fix PG 12 constraints check (provider side)
> Fix crash when deactivating vertex editor (fixes #32685)
> Fix postgis 12 adscr -> adbin consrc -> conbin
> "fix" gdal_calc creation options
> Merge pull request #32572 from qgis/backport-32527-to-release-3_4
> osgeo4w: detect grass78
> [RPM] Update sip references in spec file
> Fix copy items from value map 

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nyall Dawson]

On Sun, 24 Nov 2019 at 02:38, Jürgen E. Fischer  wrote:


> > So overall how the situation was handled doesn't seem that bad for a release
> > exercising new major dependencies.

Agreed.

I'd also like to extend Tim's thanks here and publicly state my
appreciation to Jürgen for an extremely difficult, thankless job which
you've done SO well, SO consistently and for SO long.

(And also +1 to whoever said that this was **always** going to be a
very tricky transition for the opensource geo world.It's a good thing,
but thanks to proj6 the entire software stack has been *forced* to
mature and adapt to modern, accurate projection handling and it's
causing/caused pain all round. At least we're mostly through the worst
now and it's now the users and geospatial analysts who are being
forced to mature and skill up as a consequence! And all those "data
scientists" who blundered around thinking spatial was just numeric x/y
coordinates have an even worse learning curve inbound...!)

Moving forward, I'm thinking/wondering:

Regarding 3.10.1: there's been some work in GDAL and PROJ which may
help resolve the issue which triggered this discussion. I'll test
tomorrow. I also think there's potential hacky workaround we could
implement if we avoid re-using existing PROJ context objects in
certain places (albeit with a performance hit as a result), which I'm
going to explore tomorrow as a band-aid so that we can unblock the
release.

Regarding 3.4: One option we should explore is just freezing the
Windows releases at 3.4.13, and leaving 3.4.13 as the final supported
3.4 release for Windows. (For reference, 3.4.16 is the planned final
3.4.x release, so we'd "lose" 3 months of supported new releases). I'd
personally be +1 to this, given that the existing infrastructure
cannot be easily modified to allow a proj4 based build, and adding
this support is far from trivial. While it's not ideal, I think
finalizing the Windows releases at 3.4.13 is much less risk and better
for our users then risking projection handling issues. (For full
disclosure of information I've included a list of fixes as [1] which
are included in 3.4.14 at the time of writing which would NOT be
available for Windows users as a result)


Nyall

[1]
QgsVectorFileWriter: fix axis order issue with GDAL 3 (fixes #33014)
Merge pull request #33003 from rldhont/backport-32800-to-release-3_4
Fix broken QMap finding, which causes
case-insensitive comparisons to be made when resolving primary keys in
the Oracle and Postgres providers
[Server] Update WMS GetProjectSettings tests for round extent in GetCapabilities
[Server] Test WCS Access Control: update comment
[Server] Update WCS tests for round extent in GetCapabilities
[Server] Update WMS tests for round extent in GetCapabilities
[Server] Update WFS tests for round extent in GetCapabilities
[Server] Update WMTS tests for round extent in GetCapabilities
[Server] tests: Add masks
[Bugfix][Server] Use floor and ceil for round extent coordinates in
services capabilities
[Bugfix][Server] Correctly round extent coordinates in services capabilities
Wrong label in UI for "Create point for each part" on "Centroids"
processing algorithm #32940 - Backport to 3.4
debian packaging: python-gdal still needed for gdal python scripts
Merge pull request #32749 from qgis/backport-32743-to-release-3_4
database style manager: translatable & title case
custom widgets: fix designer crash (fixes #32860)
debian packaging: drop python-gdal dependency (closes #32835) [ci skip]
qgsfunction: replace deprecated inspect.getargspec() to inspect.getfullargspec()
oracle provider: log when ROWID is used for a missing primary key
(closes #32648)
also track newer CIFS
translation string fix
Merge pull request #32460 from alexbruy/backport-32455-to-release-3_4
osgeo4w: fix nightlies (followup 766149b1b6)
In case it is needed: Update Rasterize.py for 3.4 (backport of master commit)
Update CreateConstantRaster.py
Merge pull request #32793 from
rldhont/fix-server-wfs-add-primary-keys-to-request-for-fid-34
osgeo4w: build with proj 6 and gdal 3
Fix const
[Bugfix][Server] WFS: Add primary keys to request to build Server Feature Id
Fix PG 12 constraints check (provider side)
Fix crash when deactivating vertex editor (fixes #32685)
Fix postgis 12 adscr -> adbin consrc -> conbin
"fix" gdal_calc creation options
Merge pull request #32572 from qgis/backport-32527-to-release-3_4
osgeo4w: detect grass78
[RPM] Update sip references in spec file
Fix copy items from value map configuration
[processing] allow to select files without suffix in the Processing
options dialog
fix wronng paste
fix SAGA Slope, Aspect, Curvature
dwg/dxf import: * fix orientation of TEXT entities * also clean TEXT
strings * support non-origin-based blocks * support extrusion








>
> Thank you.
>
> > …
>
> If i had to run this through a committee first, probably nothing of the above
> had happend yet and I wouldn't have time left to actually do it.
>
>
> Jürgen
>
>
> PS: Windows CI status:
>  

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Tim Sutton]

Hi

> On 23 Nov 2019, at 16:38, Jürgen E. Fischer  wrote:
> 
Snip 8<--
> More background:
> 
> * GDAL 3 requires PROJ 6
> * QGIS 3.10 has optional features that require GDAL 3,
> * GRASS uses OSGeo4W for dependencies on Windows,
> * GRASS also contributes the GRASS packages to OSGeo4W,
> * GRASS didn't support PROJ 6 & GDAL 3 until quite recently,
> * GRASS was therefore blocking the PROJ 6 and GRAL 3 updates in OSGeo4W,
> * GRASS' windows builds were not working for quite a while,
> * I introduced nightly builds of GDAL 3 and PROJ 6 next to the regular GDAL 
> and
>  PROJ packages to OSGeo4W to be able to build the QGIS nightlies against GDAL
>  3 - because the main GDAL was blocked and QGIS 3.10 with the optional 
> features
>  The release packages were still against GDAL 2.
> * The GRASS' builds were only revived after I tried to build myself and
>  contributed pull requests to fix their builds (and that still looked quite
>  familiar, because it still resembled much what I contributed years ago).
> * Those pull requests were also targeting on building GRASS with GDAL 3 and
>  PROJ 6 in OSGeo4W and gave an other already pending GRASS pull request (not
>  mine) that added GDAL 3 and PROJ 6 support a nudge and it was also merged
>  into GRASS 7.8.1.
> * When QGIS was released, GRASS was not yet released and there was no clear
>  time frame on that.  So in OSGeo4W GDAL was not updated yet and hence QGIS
>  was still built GDAL 2 and PROJ 6.
> * QGIS 3.4 supports PROJ6 - apparently not many people tried it. The LTR
>  nightlies in OSGeo4W were using it and Debian unstable also already provides
>  PROJ6.  Not many to test - but also not none.
> * People "asked" about the missing GDAL 3 features in QGIS 3.10.
> * I prepared testing packages of the upgrades (GDAL 3, PROJ 6, QGIS 3.4 and
>  3.10 and more) so that they could be used in the GRASS build, without 
> meanwhile
>  breaking the rest.
> * Those were taken live along with the GRASS packages once those arrived.
> 

8 
> PPS: I also need something to punch ;)

I know we tend to complain freely and thank frugally so let me also say a big 
’thank you’ for the work you put in trying to make your way through this 
technical stuff, juggling all these competing issues and trying to keep all the 
different personalities in the project happy. It’s an unenviable task and I 
really appreciate the level headed and thoughtful way you work through this 
stuff, thanks!

Thanks likewise to Nyall, just use a punch bag with the flat earth society logo 
on it so can remember why you are doing all this painful stuff :-P

Regards

Tim

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

On samedi 23 novembre 2019 17:44:15 CET Jürgen E. Fischer wrote:
> Hi Even,
> 
> On Sat, 23. Nov 2019 at 17:36:52 +0100, Even Rouault wrote:
> > But for the future, I can imagine we could have:
> > qgis3_10 depending on gdal3 (or possibly even gdal3_0 ?) and proj6 and
> > qt_whatever_we_use_currently
> > And qgis3_12 could decide to upgrade one of its dependencies without
> > impacting qgis3_10.
> 
> Yes, that's the route I might have followed if 3.4 didn't (claim to) support
> PROJ 6.

Actually, I *think* that QGIS 3.4 + GDAL 2.4 + PROJ 6 would probably work OK, 
because QGIS 3.4 would still use the legacy proj_api.h. The issue was more 
related to the upgrade to GDAL 3 changing how PROJ.4 strings are exported, and 
thus in practice requiring QGIS to be updated to use the new proj.h 6 API.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Even,

On Sat, 23. Nov 2019 at 17:36:52 +0100, Even Rouault wrote:
> But for the future, I can imagine we could have:
> qgis3_10 depending on gdal3 (or possibly even gdal3_0 ?) and proj6 and 
> qt_whatever_we_use_currently
> And qgis3_12 could decide to upgrade one of its dependencies without 
> impacting 
> qgis3_10.

Yes, that's the route I might have followed if 3.4 didn't (claim to) support
PROJ 6.

Although I would have sticked with qgis-ltr and qgis and just added proj5 and
gdal2.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Jürgen E . Fischer]

Hi Even,

On Fri, 22. Nov 2019 at 23:20:49 +0100, Even Rouault wrote:
> > QGIS LTR in Windows has also switched from proj 5.x and gdal 2.x to
> > proj 6.x and gdal 3.x which has resulted in some new bugs.
 
> I see 2 different situations:
 
> - 3.10 was intended to work with GDAL 3 & PROJ 6 (work started with 3.8 if I 
> remember). OSGeo4W received a late upgrade to them because GRASS 7.8 wasn't 
> ready yet for them (no offense to the GRASS team !), but devs have been able 
> to work against GDAL 3 & PROJ 6, so that wasn't unknown territory. Probably 
> that 3.10.0 could have been delayed while OSGeo4W hadn't switched to GDAL 3/
> PROJ 6, but it wasn't clear when GRASS would be out.

More background:

* GDAL 3 requires PROJ 6
* QGIS 3.10 has optional features that require GDAL 3,
* GRASS uses OSGeo4W for dependencies on Windows,
* GRASS also contributes the GRASS packages to OSGeo4W,
* GRASS didn't support PROJ 6 & GDAL 3 until quite recently,
* GRASS was therefore blocking the PROJ 6 and GRAL 3 updates in OSGeo4W,
* GRASS' windows builds were not working for quite a while,
* I introduced nightly builds of GDAL 3 and PROJ 6 next to the regular GDAL and
  PROJ packages to OSGeo4W to be able to build the QGIS nightlies against GDAL
  3 - because the main GDAL was blocked and QGIS 3.10 with the optional features
  The release packages were still against GDAL 2.
* The GRASS' builds were only revived after I tried to build myself and
  contributed pull requests to fix their builds (and that still looked quite
  familiar, because it still resembled much what I contributed years ago).
* Those pull requests were also targeting on building GRASS with GDAL 3 and
  PROJ 6 in OSGeo4W and gave an other already pending GRASS pull request (not
  mine) that added GDAL 3 and PROJ 6 support a nudge and it was also merged
  into GRASS 7.8.1.
* When QGIS was released, GRASS was not yet released and there was no clear
  time frame on that.  So in OSGeo4W GDAL was not updated yet and hence QGIS
  was still built GDAL 2 and PROJ 6.
* QGIS 3.4 supports PROJ6 - apparently not many people tried it. The LTR
  nightlies in OSGeo4W were using it and Debian unstable also already provides
  PROJ6.  Not many to test - but also not none.
* People "asked" about the missing GDAL 3 features in QGIS 3.10.
* I prepared testing packages of the upgrades (GDAL 3, PROJ 6, QGIS 3.4 and
  3.10 and more) so that they could be used in the GRASS build, without 
meanwhile
  breaking the rest.
* Those were taken live along with the GRASS packages once those arrived.

> So overall how the situation was handled doesn't seem that bad for a release
> exercising new major dependencies.

Thank you.

> …

If i had to run this through a committee first, probably nothing of the above
had happend yet and I wouldn't have time left to actually do it.


Jürgen


PS: Windows CI status:
 * appveyor: still times out (after 4 years the limit of 1h still isn't enough)
 * azure pipelines: runs out of disk space (limit 10GB)

PPS: I also need something to punch ;)

-- 
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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

On samedi 23 novembre 2019 12:23:12 CET Paolo Cavallini wrote:
> Hi Tim,
> 
> Il 23/11/19 11:22, Tim Sutton ha scritto:
> > For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
> > standalone installers but then we have an LTR that is not getting bug
> > fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
> > releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
> > have our ’stable’ version out there with no bug fixes.
> 
> yes, that's what I meant. It's a kind of bad hack, so as Bas also
> pointed out the proper solution is just to go ahead and fix the bugs.
> I feel bad about people wasting their time to fix this compatibility bug
> that will be useful just for a relatively short period, however.

I'm pretty sure there will be problems with CRS handling with QGIS 3.4 + 
GDAL3/PROJ6 that will *not* be fixable, due to intended changes of behaviour 
in GDAL3/PROJ6, particularly the export of CRS definition to PROJ strings, 
that QGIS 3.4 still uses it, that is deprecated now and works only in a 
degraded mode regarding export datum information (retrospectively, I should 
probably have completely remove exportToProj4() to make that obvious). QGIS 
3.4 to work properly with GDAL3/PROJ6 would require backporting all the PROJ6 
specific work started with 3.8, which is another big no no.

For example just seing that srs.db in 3.4.13 package has for OSGB36:
parameters (String) = +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 
+x_0=40 +y_0=-10 +ellps=airy +units=m +no_defs
where GDAL 2 based versions have an extra 
+towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 which is 
essential to make things work properly in a PROJ4 string oriented workflow as 
used by 3.4. I'v just tried with a GPKG in WGS84 with a single point in 
England, and a conversion of it to OSGB36 (with ogr2ogr of GDAL 3 or GDAL 2): 
when loaded in 3.4.13 based on GDAL 3, the points are distant of 130 m (which 
is the missing datum shift). Whereas when loaded with 3.4.13 based on GDAL 2 
(or 3.10 with GDAL 3), they overlay properly.

So people dealing with datums != WGS84 should better stick with 3.4.12 on 
Windows currently, if wanting to stay in the 3.4 series.

QGIS 3.4 combined with GDAL3/PROJ6 is a *design* bug, not a regular bug that 
can be fixed.

I don't see why QGIS 3.4 on OSGeo4W using a GDAL 2.4.3 + PROJ 5.2 
wouldn't be technically achievable. Isn't there a gdal and gdal-dev package in 
it, several QGIS variants already ? So why not a gdal2_4 ? Well, I guess that 
doing that now would require creating a grass package that depends on gdal2_4 
etc. So yes, that might be painful to do at that stage. Dunno...

But for the future, I can imagine we could have:
qgis3_10 depending on gdal3 (or possibly even gdal3_0 ?) and proj6 and 
qt_whatever_we_use_currently
And qgis3_12 could decide to upgrade one of its dependencies without impacting 
qgis3_10.

Whatever a hot fix, or a long term solution (pun intended :-)) along the above 
lines or better is chosen, it would seem to me as a very appropriate use of 
funds of the project to investigate what is possible.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Mathieu Pellerin]

Add to what was said (which I don't disagree with per say). I think it's
important to note that this GDAL3/PROJ6 transition was always going to be
rocky (whether we applied it to 3.4 LTR or delayed it of 4 months when 3.10
LTR will replace 3.4.

One reason being most core developers are on linux distributions, where a
gdal3/proj6 environment isn't available out of the box. Coupled with the
fact that our bank of daily / weekly testers is very small, we're left with
mostly devs (on linux) testing builds (which we've established are vastly
running gdal2).



On Sat, Nov 23, 2019, 21:35 kimaidou  wrote:

> HI,
> I totally agree with Nathan on this topic.
> Regards,
> Michaël
>
> Le sam. 23 nov. 2019 à 13:37, Nathan Woodrow  a
> écrit :
>
>> Hey,
>>
>> I know it has been said before, but changing the GDAL/Proj version of the
>> LTR versions is really a no go. It's a breaking change in terms of possible
>> breakages and just increases risks on a version we need to stay stable.
>>
>> We are communicating to users they should use the LTR because it's stable
>> but changing the major dependencies under the hood with new versions breaks
>> this trust and message.  It would be like changing the Qt version inside an
>> LTR point release, we just can't do it because it's a full major change
>> with massive impacts.   The risk of the LTR running on older stacks is seen
>> as a net positive not a negative when it comes to stability for users.
>>  The moment we break this trust we lose all the work past work we have put
>> in to communicate this message, trust is hard to gain and easy to lose.
>>
>> I'm not sure what the solution here is because I know OSGeo4w doesn't
>> really support that kind of separation yet but if we have a way to fund
>> this kind of work I would really like us to consider it (unsure the state
>> of the budget but this one is critical IMO).  It's going to be an ongoing
>> issue and something that will always have to be resolved with each LTR as
>> it moves away from the nightlies with the  dependencies  changing.   I wish
>> I had the skills and time to help fix this but at the moment all I can
>> offer is my concern.
>>
>> Regards,
>> Nathan
>>
>> On Sat, Nov 23, 2019 at 10:26 PM Tim Sutton  wrote:
>>
>>> Hi
>>>
>>> We also have situations like this [1] where we are breaking the LTR
>>> with. Big bumps in GDAL/PROJ version.
>>>
>>> Could we either a) invest QGIS bug fixing money into resolving these or
>>> b) adopt a more conservative approach to adopting new versions of libraries?
>>>
>>> [1]https://github.com/qgis/QGIS/issues/32953
>>>
>>> Regards
>>>
>>> Tim
>>>
>>> On 23 Nov 2019, at 11:23, Paolo Cavallini  wrote:
>>>
>>> Hi Tim,
>>>
>>> Il 23/11/19 11:22, Tim Sutton ha scritto:
>>>
>>>
>>> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
>>> standalone installers but then we have an LTR that is not getting bug
>>> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
>>> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
>>> have our ’stable’ version out there with no bug fixes.
>>>
>>>
>>> yes, that's what I meant. It's a kind of bad hack, so as Bas also
>>> pointed out the proper solution is just to go ahead and fix the bugs.
>>> I feel bad about people wasting their time to fix this compatibility bug
>>> that will be useful just for a relatively short period, however.
>>> Cheers.
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS.ORG Chair:
>>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>> —
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Tim Sutton*
>>>
>>> *Co-founder:* Kartoza
>>> *Ex Project chair:* QGIS.org
>>>
>>> Visit http://kartoza.com to find out about open source:
>>>
>>> Desktop GIS programming services
>>> Geospatial web development
>>> GIS Training
>>> Consulting Services
>>>
>>> *Skype*: timlinux
>>> *IRC:* timlinux on #qgis at freenode.net
>>>
>>> I'd love to connect. Here's my calendar link
>>>  to make finding time easy.
>>>
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: 

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[kimaidou]

HI,
I totally agree with Nathan on this topic.
Regards,
Michaël

Le sam. 23 nov. 2019 à 13:37, Nathan Woodrow  a écrit :

> Hey,
>
> I know it has been said before, but changing the GDAL/Proj version of the
> LTR versions is really a no go. It's a breaking change in terms of possible
> breakages and just increases risks on a version we need to stay stable.
>
> We are communicating to users they should use the LTR because it's stable
> but changing the major dependencies under the hood with new versions breaks
> this trust and message.  It would be like changing the Qt version inside an
> LTR point release, we just can't do it because it's a full major change
> with massive impacts.   The risk of the LTR running on older stacks is seen
> as a net positive not a negative when it comes to stability for users.
>  The moment we break this trust we lose all the work past work we have put
> in to communicate this message, trust is hard to gain and easy to lose.
>
> I'm not sure what the solution here is because I know OSGeo4w doesn't
> really support that kind of separation yet but if we have a way to fund
> this kind of work I would really like us to consider it (unsure the state
> of the budget but this one is critical IMO).  It's going to be an ongoing
> issue and something that will always have to be resolved with each LTR as
> it moves away from the nightlies with the  dependencies  changing.   I wish
> I had the skills and time to help fix this but at the moment all I can
> offer is my concern.
>
> Regards,
> Nathan
>
> On Sat, Nov 23, 2019 at 10:26 PM Tim Sutton  wrote:
>
>> Hi
>>
>> We also have situations like this [1] where we are breaking the LTR with.
>> Big bumps in GDAL/PROJ version.
>>
>> Could we either a) invest QGIS bug fixing money into resolving these or
>> b) adopt a more conservative approach to adopting new versions of libraries?
>>
>> [1]https://github.com/qgis/QGIS/issues/32953
>>
>> Regards
>>
>> Tim
>>
>> On 23 Nov 2019, at 11:23, Paolo Cavallini  wrote:
>>
>> Hi Tim,
>>
>> Il 23/11/19 11:22, Tim Sutton ha scritto:
>>
>>
>> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
>> standalone installers but then we have an LTR that is not getting bug
>> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
>> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
>> have our ’stable’ version out there with no bug fixes.
>>
>>
>> yes, that's what I meant. It's a kind of bad hack, so as Bas also
>> pointed out the proper solution is just to go ahead and fix the bugs.
>> I feel bad about people wasting their time to fix this compatibility bug
>> that will be useful just for a relatively short period, however.
>> Cheers.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> —
>>
>>
>>
>>
>>
>>
>>
>>
>> *Tim Sutton*
>>
>> *Co-founder:* Kartoza
>> *Ex Project chair:* QGIS.org
>>
>> Visit http://kartoza.com to find out about open source:
>>
>> Desktop GIS programming services
>> Geospatial web development
>> GIS Training
>> Consulting Services
>>
>> *Skype*: timlinux
>> *IRC:* timlinux on #qgis at freenode.net
>>
>> I'd love to connect. Here's my calendar link
>>  to make finding time easy.
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

Hey,

I know it has been said before, but changing the GDAL/Proj version of the
LTR versions is really a no go. It's a breaking change in terms of possible
breakages and just increases risks on a version we need to stay stable.

We are communicating to users they should use the LTR because it's stable
but changing the major dependencies under the hood with new versions breaks
this trust and message.  It would be like changing the Qt version inside an
LTR point release, we just can't do it because it's a full major change
with massive impacts.   The risk of the LTR running on older stacks is seen
as a net positive not a negative when it comes to stability for users.
 The moment we break this trust we lose all the work past work we have put
in to communicate this message, trust is hard to gain and easy to lose.

I'm not sure what the solution here is because I know OSGeo4w doesn't
really support that kind of separation yet but if we have a way to fund
this kind of work I would really like us to consider it (unsure the state
of the budget but this one is critical IMO).  It's going to be an ongoing
issue and something that will always have to be resolved with each LTR as
it moves away from the nightlies with the  dependencies  changing.   I wish
I had the skills and time to help fix this but at the moment all I can
offer is my concern.

Regards,
Nathan

On Sat, Nov 23, 2019 at 10:26 PM Tim Sutton  wrote:

> Hi
>
> We also have situations like this [1] where we are breaking the LTR with.
> Big bumps in GDAL/PROJ version.
>
> Could we either a) invest QGIS bug fixing money into resolving these or b)
> adopt a more conservative approach to adopting new versions of libraries?
>
> [1]https://github.com/qgis/QGIS/issues/32953
>
> Regards
>
> Tim
>
> On 23 Nov 2019, at 11:23, Paolo Cavallini  wrote:
>
> Hi Tim,
>
> Il 23/11/19 11:22, Tim Sutton ha scritto:
>
>
> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
> standalone installers but then we have an LTR that is not getting bug
> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
> have our ’stable’ version out there with no bug fixes.
>
>
> yes, that's what I meant. It's a kind of bad hack, so as Bas also
> pointed out the proper solution is just to go ahead and fix the bugs.
> I feel bad about people wasting their time to fix this compatibility bug
> that will be useful just for a relatively short period, however.
> Cheers.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Tim Sutton]

Hi

We also have situations like this [1] where we are breaking the LTR with. Big 
bumps in GDAL/PROJ version.

Could we either a) invest QGIS bug fixing money into resolving these or b) 
adopt a more conservative approach to adopting new versions of libraries?

[1]https://github.com/qgis/QGIS/issues/32953 


Regards

Tim

> On 23 Nov 2019, at 11:23, Paolo Cavallini  wrote:
> 
> Hi Tim,
> 
> Il 23/11/19 11:22, Tim Sutton ha scritto:
> 
> 
>> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
>> standalone installers but then we have an LTR that is not getting bug
>> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
>> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
>> have our ’stable’ version out there with no bug fixes.
> 
> yes, that's what I meant. It's a kind of bad hack, so as Bas also
> pointed out the proper solution is just to go ahead and fix the bugs.
> I feel bad about people wasting their time to fix this compatibility bug
> that will be useful just for a relatively short period, however.
> Cheers.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Paolo Cavallini]

Hi Tim,

Il 23/11/19 11:22, Tim Sutton ha scritto:


> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
> standalone installers but then we have an LTR that is not getting bug
> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
> have our ’stable’ version out there with no bug fixes.

yes, that's what I meant. It's a kind of bad hack, so as Bas also
pointed out the proper solution is just to go ahead and fix the bugs.
I feel bad about people wasting their time to fix this compatibility bug
that will be useful just for a relatively short period, however.
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Borys Jurgiel]

Thanks Even! I was mislead by the hard freeze and had an impression 3.10 is 
going to be more stable than it actually was meant to be. I'm often not sure 
what level of predictability we can expect from the official builds and your 
response shreds more light on it.

And, first of all, big thanks to Nyall for working on fixing it!

Regards,
Borys

Dnia piątek, 22 listopada 2019 23:20:49 CET Even Rouault pisze:
> > QGIS LTR in Windows has also switched from proj 5.x and gdal 2.x to
> > proj 6.x and gdal 3.x which has resulted in some new bugs.
> 
> I see 2 different situations:
> 
> - 3.10 was intended to work with GDAL 3 & PROJ 6 (work started with 3.8 if I
> remember). OSGeo4W received a late upgrade to them because GRASS 7.8 wasn't
> ready yet for them (no offense to the GRASS team !), but devs have been
> able to work against GDAL 3 & PROJ 6, so that wasn't unknown territory.
> Probably that 3.10.0 could have been delayed while OSGeo4W hadn't switched
> to GDAL 3/ PROJ 6, but it wasn't clear when GRASS would be out. So overall
> how the situation was handled doesn't seem that bad for a release
> exercising new major dependencies.
> 
> - I do agree that the switch to GDAL 3 & PROJ 6 for a near end-of-life 3.4
> LTR was unfortunate (but more than the timing, that does not seem
> appropriate for a release which was not designed originally to work with
> them) and I felt -0 on that.
> 
> > It will be additional work for package managers and more resources, but it
> > will be good to have some guidelines on LTR and PRs dependencies for
> > packaging.
> 
> Each LTR should ideally have its own set of dependencies, allowing
> controlled changes of them when needed (adopting a new bugfix version might
> be OK), and allowing the current version to use more aggressively new
> versions of the dependencies. That said, I'm not a packager, and don't know
> the effort & cost associated, but that's clearly an area where the project
> could/should invest. Similar situation is likely to happen again in the
> future.
> 
> I'm also wondering if there shouldn't be a vote, from developers, PSC, bug
> triagers, testers or probably a mix of them forming a representative body,
> to adjudicate:
> - dependency upgrades
> - decision of releasing a new version (most other OSGeo projects I'm
> familiar with rely on a PSC formal vote to issue releases (*)).
> 
> Or one might consider a mixed approach to have a good compromise of agility
> vs tighter control:
> - use time-based approach, as done currently, for non-LTR versions.
> - formally approve the release of LTR versions, and important engineering
> decisions that affect them, as there are the ones with the most user
> exposure. Sometime ago I also suggested to possibly consider 2 phases in a
> LTR life- cycle: first half where quite "aggressive" backporting is
> accepted (if it doesn't break API, etc..), second half where a much more
> conservative approach is taken. It is rather obvious that a .0, .1 needs
> more stabilization than a . 12 or a .13
> 
> Just food for thought :-)
> 
> Even
> 
> (*) even bugfix ones, which is admidetly sometimes a bit overkill




___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Sebastiaan Couwenberg]

On 11/23/19 9:05 AM, Paolo Cavallini wrote:
> IMHO the LTR should be as stable as possible, so I agree that changing
> things now it's unfortunate.

Changing dependencies are pretty much inevitable, LTR needs to adapt to
those or become unusable which defeats the purpose of LTR.

PROJ 6 & GDAL 3 are major changes and updating distributions when QGIS
3.10 supports them well is good time do migrate to them.

We're in the process to migrate to PROJ 6 and GDAL 3 in Debian as well,
we've had PROJ 6 in testing/unstable for a while now and GDAL 3
hopefully follows after the ongoing python3.8 transition. We'll have
QGIS 3.4 LTR built with that for now, until we switch the package to
3.10 once that becomes the new LTR and have the qgis package make full
use of PROJ 6 & GDAL 3.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Tim Sutton]

Hi Paolo



> On 23 Nov 2019, at 08:05, Paolo Cavallini  wrote:
> 
> Hi all,
> 
> Il 22/11/19 23:20, Even Rouault ha scritto:
> 
>> Or one might consider a mixed approach to have a good compromise of agility 
>> vs 
>> tighter control:
>> - use time-based approach, as done currently, for non-LTR versions.
>> - formally approve the release of LTR versions, and important engineering 
>> decisions that affect them, as there are the ones with the most user 
>> exposure. 
>> Sometime ago I also suggested to possibly consider 2 phases in a LTR life-
>> cycle: first half where quite "aggressive" backporting is accepted (if it 
>> doesn't break API, etc..), second half where a much more conservative 
>> approach 
>> is taken. It is rather obvious that a .0, .1 needs more stabilization than a 
>> .
>> 12 or a .13
>> 
>> Just food for thought :-)
>> 
>> Even
>> 
>> (*) even bugfix ones, which is admidetly sometimes a bit overkill
>> 
> 
> Thanks everybody for the analysis and the proposals.
> IMHO the LTR should be as stable as possible, so I agree that changing
> things now it's unfortunate.
> An alternative is to freeze it, and don't release further updates. Are
> there important bugfixes preventing us to do so?

If I understand the situation properly, it is not possible to do this in the 
OSGEO4W framework (and maybe similar issue in Debian etc) since in OSGEO4W 
online installer there is only one proj, GDAL etc published and you cannot have 
e.g. QGIS  3.4.x depending on project 5 and QGIS 3.10.x depending on Proj 6 
both both within the same OSGEO4W package tree. I think similar issue arises in 
Debian. I may be totally misreading the situation (I am sure Jürgen will 
correct me if I am :-) ).In the OSGEO4W side we would basically need to ask / 
fund Jürgen to support different packages for different versions of QGIS which 
I suspect may be a major pain in the butt.

For windows at least we could ‘freeze’ 3.4.x by pointing them to use the 
standalone installers but then we have an LTR that is not getting bug fixes. As 
I read Jürgen’s roadmap [1] we still have 4 more bug fix releases of 3.4 before 
3.10 becomes LTR, which is quite a long time to have our ’stable’ version out 
there with no bug fixes.

PR  3.10.1  3.4.14  2019-11-29  48  3
PR  3.10.2  3.4.15  2019-12-20  51  4
PR/FF   3.10.3  3.4.16  3.112020-01-17  3   5
LR/PR   3.12.0  3.10.4  2020-02-21  8   4
Regards

Tim



[1] https://www.qgis.org/en/site/getinvolved/development/roadmap.html 

> Cheers.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Paolo Cavallini]

Hi all,

Il 22/11/19 23:20, Even Rouault ha scritto:

> Or one might consider a mixed approach to have a good compromise of agility 
> vs 
> tighter control:
> - use time-based approach, as done currently, for non-LTR versions.
> - formally approve the release of LTR versions, and important engineering 
> decisions that affect them, as there are the ones with the most user 
> exposure. 
> Sometime ago I also suggested to possibly consider 2 phases in a LTR life-
> cycle: first half where quite "aggressive" backporting is accepted (if it 
> doesn't break API, etc..), second half where a much more conservative 
> approach 
> is taken. It is rather obvious that a .0, .1 needs more stabilization than a .
> 12 or a .13
> 
> Just food for thought :-)
> 
> Even
> 
> (*) even bugfix ones, which is admidetly sometimes a bit overkill
> 

Thanks everybody for the analysis and the proposals.
IMHO the LTR should be as stable as possible, so I agree that changing
things now it's unfortunate.
An alternative is to freeze it, and don't release further updates. Are
there important bugfixes preventing us to do so?
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer