[PROJ] Future maintainance releases

[Kristian Evers]

>> I think we have some fundamentally different assumptions about things,
>> both reasonable in their own right, but I'll try to lay out how I think
>> you see it and then how I do.

Greg, I am well aware of the intricacies of packaging systems. It is not simple
and you and Bas have difficult task of making it all fit together. Please don’t
think that I don’t understand or respect the job you do.

I am also aware that PROJ has made a lot of changes over a somewhat short
time. I would love to live in a world where that wasn’t necessary but unfortunately
PROJ was in an less than ideal state for far too long. It is no ones fault, it is just
the way things turned out. Now we are catching up and that means moving quickly
for a bit. I think most agrees that this is the right thing to do. I also know that it is
a difficult task to migrate from one API to the other. I believe the benefits of the
new features in PROJ is worth it. I also think that PROJ 6 is a good bridge between
the new and the old. I fully expect PROJ 6 to be around in packaging systems
for quite some time still. But I also fear that most projects will be stuck using the
old API forever if we keep hanging on to proj_api.h. Were that to happen I would
be extremely discouraged from working on PROJ - my motivation is to bring
better use of geodesy to the masses. We can’t do that properly through the old
API.

I think what we have now is a good compromise: Those that can use PROJ 
 when it comes out and get the benefit of regular updates to the EPSG database
etc. And those who can’t use PROJ 7 just yet can still use the 6.x branch which
is already rather good. Should it prove necessary we will release maintenance
releases of the 6.x branch, at least for the first year of it being superseded by
PROJ 7.

> Proj didn’t want to shim between the old and new APIs any more... which meant the shim just migrated out one level. So now we have one. I’m sure others will too 😂


Yes, this is unfortunate but I really can’t see any way around that. Except from
freezing time at PROJ 4.9.3… 

/Kristian


> On 31 Oct 2019, at 02:11, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> Just have to put the oar in 😁
> 
> ... and then there is the fun of being a dependent program and realistically having to support both versions for N years. Proj didn’t want to shim between the old and new APIs any more... which meant the shim just migrated out one level. So now we have one. I’m sure others will too 😂
> 
> P
> 
>> On Oct 30, 2019, at 5:58 PM, Greg Troxel <gdt at lexort.com> wrote:
>> 
>> Kristian Evers <kreve at sdfe.dk> writes:
>> 
>>>> On 30 Oct 2019, at 14:45, Greg Troxel <gdt at lexort.com> wrote:
>>>> 
>>>> Bas Couwenberg <sebastic at xs4all.nl> writes:
>>>> 
>>>>> [info about proj6 migration status]
>>>> 
>>>> From my perspective on packaging many things, proj's trajectory of
>>>> deprecations is already feeling very rapid compared to how many things
>>>> depend on it.   Realize that people are still in the process of getting
>>>> off qt4.
>>>> 
>>>> pkgsrc is in a similar position to Debian, although less well baked,
>>>> with proj6 in wip (sort of like Debian unstable, but not really), and
>>>> having to define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H to keep some things
>>>> building.
>>>> 
>>>> I don't want to have multiple proj versions in pkgsrc, and I don't want
>>>> to preclude libosmium, libspatialite, mapnik.
>>>> 
>>>> I feel that the "rip the bandaid off" notion is counterproductive, as it
>>>> really means "break things for users so that packagers have to decide
>>>> between old proj and dropping dependencies”.
>>> 
>>> I don’t think that is a fair way to lay it out. From the beginning we've had
>>> a “double-feature” in the release schedule for the 7.0.0 release with an
>>> accompanying 6.x-release. This is still the plan and if it turns out to be
>>> necessary we can put out more releases of the 6.x branch later on. Users
>>> of proj_api.h should be taken care of for at least a year or two more with
>>> the 6.3.1 release. But at some point support for 6.x has to stop. I don’t
>>> want to see us move into Python2 territory!
>> 
>> I think we have some fundamentally different assumptions about things,
>> both reasonable in their own right, but I'll try to lay out how I think
>> you see it and then how I do.
>> 
>> 
>> I think you are seeing that there are people that are wanting to compile
>> a single program that depends on proj, and that might or might not use
>> proj_api.h (meaning that they need proj 6, and 7 will not do).  Then
>> these people would choose either 6.x (if the program uses proj_api.h) or
>> 7 (if it doesn't), build proj, and then build the program they want to
>> use.
>> 
>> As I see it, nearly 100% of the uses of any popular program are via some
>> packaging system.  So users type "pkg_add qgis" (if they are the unusual
>> ones that use pkgsrc :-), "apt install qgis" (ish), or something that
>> amounts to the same thing.  This gets them -- as an automatic dependency
>> --the proj version chosen by the people curating the packaging system --
>> which is people like Bas and me.  Most users don't know how to build
>> things; they rely on binary packages prepared by packaging systems.
>> 
>> Packagers have a big first choice: does the packaging system use a
>> single version of proj, or does it have some scheme to have multiple
>> versions and somehow namespace them to permit simultaneous use.
>> 
>> If a single, then do we choose 6.x, and leave out features, or do we
>> choose 7.x and *entirely drop* packages that still use proj_api in their
>> *latest formal release* from the packaging system?
>> 
>> If we go down the multiple path, then how do we organize things where
>> (making things up) qgis depends on proj and can use 7, but qgis depends
>> on libspatialite which needs proj_api and thus 6.  But any one program
>> can only link one proj.  Plus, multiple parallel-installable versions is
>> hard, and in pkgsrc we use that mostly for things like python.
>> 
>> Right now, pkgsrc is not even updating to proj 6, but has it in a
>> staging area.  Probably it's about time to really update.  Debian is in
>> process -- I just read that it's in unstable but not yet in a formal
>> release.  This delay in moving both pkgsrc and Debian from 5 to 6 is
>> already gated by compatibility issues; if every program that compiled
>> with 5 built with 6, it would have just been updated quickly, with no
>> wailing and gnashing of teeth.
>> 
>> That's a long way of saying that "users can just use 6 if they need to"
>> doesn't fit with the my notion of how users rely on a collection of
>> binary packages.  Hence that releasing 7 with an API break leaves
>> packagers with the choice of "don't give 7 to users" vs "drop things
>> that don't build with 7"
>> 
>> 
>> All of this leads to the issue of "but things have been deprecated for a
>> wicked long time (as we say in Boston)".  Unquestionably true.  But I
>> have seen over the years that when a package is foundational and very
>> widely used, that API withdrawals take a very long time to completely
>> ripple through the ecosystem.  In pkgsrc we are just dealing with
>> removing qt4 (and Debian is only a few steps ahead of us, struggling
>> with exactly the same issues).  Programs from high-functioning upstreams
>> with regular release like GNU Radio have made releases as recent as
>> April 2019 which use qt4, even though the last release of qt4 was in
>> April of 2015, and it went EOL at the end of 2015.
>> 
>> 
>> I'm not trying to say specifically what you should do.  Just that when
>> there is a new release with an API withdrawal, then packagers have to
>> choose between not updating and dropping things that don't build or
>> can't easily be patched to build.   If the notion is that 7 will be
>> released but you don't expect packaging systems to adopt it, that's
>> perhaps an interesting situation that I haven't really pondered.
>> 
>> (speaking only for me, of course)
>> 
>> Greg
>> 
>> 
>> _______________________________________________
>> PROJ mailing list
>> PROJ at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/proj