[QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]
Paolo Cavallini
cavallini at faunalia.it
Thu Nov 28 00:19:16 PST 2019
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
>>> <nirvn.asia at gmail.com <mailto:nirvn.asia at gmail.com>> wrote:
>>>
>>> +1 to end 3.4 cycle a few months early too.
>>>
>>> On Thu, Nov 28, 2019, 05:57 Nathan Woodrow <madmanwoo at gmail.com
>>> <mailto:madmanwoo at 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,
>>> <even.rouault at spatialys.com
>>> <mailto:even.rouault at 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 at lists.osgeo.org
>>> <mailto:QGIS-Developer at 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 at lists.osgeo.org
>>> <mailto:QGIS-Developer at 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 at lists.osgeo.org <mailto:QGIS-Developer at 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 at lists.osgeo.org <mailto:QGIS-Developer at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
More information about the QGIS-Developer
mailing list