[postgis-devel] liblwgeom versioning

[Stephen Frost]

* Sandro Santilli (strk at keybit.net) wrote:
> On Thu, Oct 08, 2015 at 09:23:28AM -0400, Greg Troxel wrote:
> > >> Do you expect there to be an ABI break in liblwgeom in every postgis
> > >> major (e.g. 2.2 to 2.3) release?
> > >
> > > Not necessarely, but since liblwgeom is shipped with postgis, rather
> > > than having its own release cycle, keeping it bound to the PostGIS
> > > branch name (Major.Minor) is to reduce headaches...
> > 
> > How does that reduce headaches?  As I see it, all it does is
> > 
> >   - (potentially) introduce ABI breaks that are not necessary
> >   - propagate the confusion that shlib names should change at releases,
> >     while
> > 
> >   + avoid having to keep track of ABI breaks
> 
> Actually keep trac of ABI breaks is still needed, as you saw
> in this case we're discussing (broke between 2.2.0 and 2.2.1).

Yes, ABI changes still need to be tracked, but generally speaking
there's two things to worry about- *backwards-incompatible* ABI changes
and *backwards-compatible* ABI changes.

> The headaches it removes is the handling of branches.
> 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.

That's where the release policy bit comes into play.  If you're willing
to do a *backwards-incompatible* change in a released branch, then you
do have to consider all of the branches, but, honestly, that's not a
good thing to be doing and should be rare enough and important enough
that you need to bump across all of the released branches *anyway*
(major security issue which requires an ABI break or some such).

Further, there would be serious push-back about even bumping the minor
in a released branch because that implies that you're adding some kind
of new functionality or new feature to the library, and we don't do that
in minor releases.

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?

> 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.  For example, I've
got PostgreSQL 9.2, 9.3, and 9.4 installed (from packages) on my
laptop, but the only version of libpq installed is the one from 9.4,
since it's the most recent and the major SO is the same across all of
those major release versions of PG.

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.

> > And if you don't do that, then the postgis build will find an installed
> > liblwgeom and link against it (or fail)?   My point is that if these are
> > two things, they really should be two things (or should be easily and in
> > a supported manner be treatable that way).
> 
> 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.

> > If liblwgeom is going to become its own thing, arguably it should have
> > its own tarball and release, even if sychronized.
> 
> Agreed. We're just not there yet, for the maintainance cost it has.

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!

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20151008/31947078/attachment.sig>