[postgis-devel] liblwgeom versioning

[Sandro Santilli]

On Thu, Oct 08, 2015 at 10:16:18AM -0400, Stephen Frost wrote:
> * Sandro Santilli (strk at keybit.net) wrote:

> > Consider this scenario (with Major.Minor removed):
> > 
> >  1. PostGIS-2.2.1 is released, shipping liblwgeom.so.3.0.0
> >  2. PostGIS-2.3.0 is released, shipping liblwgeom.so.3.0.1 
> >  3. PostGIS-2.2.2 is released, shipping liblwgeom.so.3.0.? 
> 
> In PG, we don't bump the SONAME during a given major release, but we do
> bump the minor SONAME for every major release, so we don't have to
> explicitly track *backwards-compatible* changes.

Ok, so if we also did that, we'd have:

  1. PostGIS-2.2.1 is released, shipping liblwgeom.so.3.0.0
  2. PostGIS-2.3.0 is released, shipping liblwgeom.so.3.1.0 
  3. PostGIS-2.2.2 is released, shipping liblwgeom.so.3.0.1 

Now say there's a fix that needs ABI breakage, we'd have
to then ship:

  4. PostGIS-2.2.3 with liblwgeom.so.4.0.0
  5. PostGIS-2.3.1 with liblwgeom.so.4.1.0 

Is that correct ?
That is, any branch that needs the fix would have a a new version
of liblwgeom..

> The last major bump we did was to strip out the not-intended-for-export
> symbols (previously, we just exported everything).  Doing that reduces
> the set of symbols that you have to pay attention to when it comes to
> considering if there is an ABI change and generally makes things
> cleaner- are you doing that today?

Nope, but recently planned: https://trac.osgeo.org/postgis/ticket/3305

> > Or, in other words, the liblwgeom "branches" would mismatch from
> > the postgis "branches". This is the headache I'm trying to avoid
> > here. The only solution would be having a different repository
> > for liblwgeom (but OSGeo is still not ready with hosting git
> > repositories and the headaches augments...).
> 
> What I think it missing from this is that the libraries don't get
> updated in the same way that the applications do.

In the case of PostGIS that's really a _maybe_, in that hardly
any PostGIS release did not add something to liblwgeom.

> Having libpq4 and libpq5 installed *should* be supported though, but
> you do have to consider what happens if both end up loaded into the same
> binary (probably because of various other libraries which have been
> pulled in and built at different times)- that's where symbol versioning
> can be used to keep them distinct though.

Do you use symbol versioning ? Or let builders decide ?

> > PostGIS never looks for an installed liblwgeom, with current
> > build scripts. It links statically against the version of liblwgeom
> > shipped togheter with it. This may change in case enough support for
> > such a move is found (among developers and or sponsors).
> 
> I'd certainly like to see it *stop* being statically linked in.

Once we get correct liblwgeom versioning, I guess we could do that.
It's discussed here: https://trac.osgeo.org/postgis/ticket/3290

> I don't believe it's necessary for it to have an independent tarball and
> release.  We don't do that for PG and libpq.  On the other hand, I
> wouldn't be against it having an independent tarball/release, if that's
> what people want to do.

Thanks for your comments, Stephen.

--strk;