Re: Future maintainance releases

> On 1 Nov 2019, at 19:53, Greg Troxel <[email protected]> wrote:
> 
> Kristian Evers <[email protected]> writes:
> 
>> 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.
> 
> Certainly I realize this is all very complicated with no 100% wonderful
> approaches.
> 
>> 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.
> 
> 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. 

> 
> 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.
> 

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 :-)

/Kristian

> 
> _______________________________________________
> PROJ mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj