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] Drill-down forms with multiple selections option

[Pedro Venâncio]

Hi Alexandre,

You are the man!

For the record, I leave the filter expression from Alexandre Neto, that
work like a charm:

eval(' "di" in' + replace(current_value(
'DISTRITOS'),array('{','}','"'),array('(',')','\'')))

Thank you very much Alex!

Best regards,
Pedro


Alexandre Neto  escreveu no dia sábado, 23/11/2019
à(s) 16:58:

> Hi Pedro,
>
> Can't you check if  "di" is present in the {Value1,Value2,...} set?
>
> If needed, you can replace the curly brackets by curved ones and run the
> all expression by eval()
>
> Alexandre Neto
>
> A sábado, 23/11/2019, 13:48, Pedro Venâncio 
> escreveu:
>
>> Hi all,
>>
>> I'm building a form with two fields of "Value Relation Widgets", one
>> depending on the other.
>>
>> This works really well as explained here https://youtu.be/ipezh4KXrgo by
>> Alessandro, but I would like that both fields have the multiple selections
>> option.
>>
>> Here is a sample project:
>> https://cld.pt/dl/download/db1a1787-0adc-4633-a0c9-356c41f269eb/drilldown_multiple.zip
>>
>> In that project, I have two shapefiles (one configured without and
>> another configured with 'Allow multiple selections') and two csv files
>> (Value Relation sources).
>>
>> So, without multiple selections option, I simply use
>> "di" = current_value( 'DISTRITOS')
>> as filter expression.
>>
>> This does not work with multiple selections, because this option saves
>> the multiple values between braces: {Value1,Value2,...}.
>>
>> So, how could I use the filter here, to have the second field filtered by
>> the options selected in the first field?
>>
>> Thank you very much!
>>
>> Best regards,
>> Pedro Venâncio
>> ___
>> 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

> 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] Drill-down forms with multiple selections option

[Alexandre Neto]

Hi Pedro,

Can't you check if  "di" is present in the {Value1,Value2,...} set?

If needed, you can replace the curly brackets by curved ones and run the
all expression by eval()

Alexandre Neto

A sábado, 23/11/2019, 13:48, Pedro Venâncio 
escreveu:

> Hi all,
>
> I'm building a form with two fields of "Value Relation Widgets", one
> depending on the other.
>
> This works really well as explained here https://youtu.be/ipezh4KXrgo by
> Alessandro, but I would like that both fields have the multiple selections
> option.
>
> Here is a sample project:
> https://cld.pt/dl/download/db1a1787-0adc-4633-a0c9-356c41f269eb/drilldown_multiple.zip
>
> In that project, I have two shapefiles (one configured without and another
> configured with 'Allow multiple selections') and two csv files (Value
> Relation sources).
>
> So, without multiple selections option, I simply use
> "di" = current_value( 'DISTRITOS')
> as filter expression.
>
> This does not work with multiple selections, because this option saves the
> multiple values between braces: {Value1,Value2,...}.
>
> So, how could I use the filter here, to have the second field filtered by
> the options selected in the first field?
>
> Thank you very much!
>
> Best regards,
> Pedro Venâncio
> ___
> 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]

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

[QGIS-Developer] Drill-down forms with multiple selections option

[Pedro Venâncio]

Hi all,

I'm building a form with two fields of "Value Relation Widgets", one
depending on the other.

This works really well as explained here https://youtu.be/ipezh4KXrgo by
Alessandro, but I would like that both fields have the multiple selections
option.

Here is a sample project:
https://cld.pt/dl/download/db1a1787-0adc-4633-a0c9-356c41f269eb/drilldown_multiple.zip

In that project, I have two shapefiles (one configured without and another
configured with 'Allow multiple selections') and two csv files (Value
Relation sources).

So, without multiple selections option, I simply use
"di" = current_value( 'DISTRITOS')
as filter expression.

This does not work with multiple selections, because this option saves the
multiple values between braces: {Value1,Value2,...}.

So, how could I use the filter here, to have the second field filtered by
the options selected in the first field?

Thank you very much!

Best regards,
Pedro Venâncio
___
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] Geometry generator expression for line segment length

[Anita Graser]

Fixing the code prefix fixed the issue. Thanks Nyall!

Ad proj build: funnily enough, QGIS aboug says "Running against PROJ Rel.
7.0.0, March 1st, 2020"  ... Welcome to the future!

Anita

On Mon, Nov 18, 2019 at 9:36 AM Anita Graser  wrote:

>
>
> On Mon, Nov 18, 2019 at 4:40 AM Nyall Dawson 
> wrote:
>
>> On Fri, 15 Nov 2019 at 05:34, Anita Graser  wrote:
>> >
>> > Hi,
>> >
>> > I recently noticed that the expression I used in
>> https://anitagraser.com/2016/10/09/movement-data-in-gis-2-visualization/
>> does not work in current QGIS versions anymore. Specifically, I computed
>> the metric length of a line segment by transforming from WGS84 'EPSG:4326'
>> to 'EPSG:54027':
>> >
>> > length(
>> >   transform(
>> > geometry_n($geometry,@geometry_part_num),
>> > 'EPSG:4326','EPSG:54027'
>> > )
>> > )
>> >
>> > While debugging, I found that the transformation is not applied
>> anymore. (Some other EPSG codes do work though.) However, I couldn't figure
>> out how to get this transformation to work again.
>>
>> Is this a proj 6 based build? In any case, EPSG:54027 doesn't exist.
>> The correct code is "ESRI:54027" (see https://epsg.io/54027).
>
>
> Good catch, different four letters starting with E! The issue appeared on
> OSGeo4W so I'll have to check if that means proj6 already. Anyway, I'll
> give the other code a try!
>
> Thanks
> Anita
>
>
>
>
>> It's
>> possible that < proj 6 builds had some exception in place for this
>> particular CRS, but with a proj 6 based build we rely on proj to
>> interpret CRS auth/id pairs so any exceptions in place for earlier
>> QGIS versions won't apply anymore.
>>
>> 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?]

[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