Re: Future maintainance releases

> Yes, but I am saying that means *only 6.x* in the packaging system.

I know. Apparently my communication skills are rubbish. This is the
situation I've been talking about all along. Packaging systems will
more or less always be lagging behind. In this case it will be lagging
more. Fully expected. 

> But I think we are asympotically close to understanding each other, and
we'll muddle through :-)

I think so too. Hopefully everything works out in the end :-)

/Kristian

-----Original Message-----
From: Greg Troxel <[email protected]> 
Sent: 2. november 2019 02:55
To: Kristian Evers <[email protected]>
Cc: [email protected]
Subject: Re: [PROJ] Future maintainance releases

Kristian Evers <[email protected]> writes:

>> I still am missing something.   When 7 comes out, with a packaging
>> system that has a single proj version, what version do you think that
>> should be?
>
> With many applications still relying on proj_api.h I would think that a
> version from the 6.x branch should be in the packaging system. 

Yes, but I am saying that means *only 6.x* in the packaging system.

To have both requires us to be able to simultaneously install 6.x and
7.x; it's not reasonable to prohibit simultaneously installing two
things that depend on different proj versions.  That requires some
namespacing scheme, and given how -L/-R library searching works, it more
or less means having different names for the libraries, which means
something like proj6.so and proj7.so, and then pkgconfig/etc. support to
find that, and support in all the depending packages to find the right
ones.  So far, I haven't seen any discussion of upstream proj starting
to do this, and it feels like tilting at windmills to start to patch
this in as a packager.

>> Do you mean that by having 7 released, then there can be a year of
>> packaging sytems having 6, during which time upstreams of proj-using
>> packages can be pressured to make a formal release which is compatible
>> with proj 7?   In all seriousness, this might be the best that can be
>> realistically hoped for.

(I meant "having only 6", just like they now have only 5, and not yet 6.)

> Yes, something like that. A preliminary release schedule after the 7.0.0
> release look something like:
>
> March 1st 2020:	7.0.0 + 6.3.1
> June 1st 2020:	7.0.1 + 6.3.2
> September 2020:	7.1.0 (+ 6.3.3)
> December 2020:	7.1.1
> March 1s 2021:	7.2.0
>
> I won’t commit to too many maintenance release of 6.3 branch since it may
> diverge from master rather quickly. I don’t know exactly what the shelf-life of
> a PROJ release is, but let’s say that it is a year. Then you’d have a soft
> end-of-life of PROJ 6.x either in the middle or end of 2021. That leaves roughly
> two years from now to coerce the lagging projects to adopt the new API. If a
> project still hasn’t made the transition in that time I fear they never will.
>
> I hope the above is manageable. Otherwise I am not sure what to do, apart from
> keeping 6.x alive indefinitely, which to no surprise is not going to happen :-)

I epxect packaging systems to just have 6 -- perhaps starting around the
time 6.3.1 is releaesd in March, and then to move to just 7 perhaps in
March of 2021, dropping things that don't have support for 7.   I don't
expect pkgsrc to try to have two at once, especially without explicit
upstream support for parallel installs.  I'll let Bas comment on guesses
for what Debian might do, and of course anybody else who deals with any
other system.


But I think we are asympotically close to understanding each other, and
we'll muddle through :-)
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj