[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

[Regina Obe]

>> > And both have the issue Regina is complaining about of adding
>> > support for future PostgreSQL versions in old PostGIS branch or viceversa
>> > (maintain support for old PostgreSQL versions).
>> 
>>  Isn't that something you would want to be doing anyway..?

> Possibly, but there must be an end-of-life at one point.

Not always the reason being that every time PostgreSQL releases a new version (now Major version)  
It often requires us to make none trivial changes to stable versions of PostGIS .  These changes may in some cases may destabilize a stable version.

e.g. we have to add a new header file, put in a bunch of #if #defs to handle newer
and on top of that test to make sure it behaves correctly for the life of the the PostgreSQL version.

In PostgreSQL 10, there were breaking SQL changes that required us to rewrite some of our SQL functions and tests in PostGIS 2.4

Such things are just not maintainable.  It would be so much better if we can say 

Yes -- we have put in effort in PostGIS 2.4.0 for breaking changes that got added to PostgreSQL 10, please use that instead of trying to use PostGIS 2.3.

If PostGIS 2.3 worked fine out of the gate with minimal changes to support PostgreSQL 10, I wouldn't be so against supporting PostGIS 2.3 on PostgreSQL 10.

Even now, PostgreSQL 11 has already made changes that broke PostGIS 2.4 on PostgreSQL 11, so we'll probably have to address that if we don't think we can release PostGIS 2.5 in time.

This is also the same reason we don't go thru too much trouble to support older versions of PostgreSQL on newer versions of PostGIS. It forces us to use long deprecated PostgreSQL APIs or put in a lot of 
#if #def duplicated code.

To Mark's comment about ABI compatibility

It's rare  we break that pre-Major release and when we did (I think it was a mistake because somebody felt like changing a name in a function cause he didn't like it :))) ).
If we do such things, it would do us good to be more deliberate about it, like for example calling it  postigs-2-break1.

For the hassle we cause people trying to pg_upgrade when we rarely  break ABI between minors  is so heart-breaking to me :)

Anyway what's done is done.  I agree with Mark and Greg that we shouldn't rush into this so close to release time 
but reconsider it for PostGIS 2.5 or come up with changes that can be done with pg_upgrade to address in future.


Thanks,
Regina