[postgis-devel] liblwgeom versioning

[Stephen Frost]

Sandro,

* Sandro Santilli (strk at keybit.net) wrote:
> 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..

Yes, any branch that needs the fix needs to have its SONAME changed-
which is pretty likely to be every branch from current back to the point
where the issue was introduced.

Remember, this is for a backwards-incompatible ABI change.  By
definition, that can't apply to something which was broken and an older
release and fixed in a newer one- because fixing whatever it was would
have introduced an ABI break.  The only potential confusion here is if
you have some other ABI break which causes the under-development version
to have already bumped the SONAME, in which case you don't *technically*
have to bump the SONAME again since you haevn't released yet, but it's
not like it would hurt to do so either.

Again, this should really be *very* rare and effort should be taken to
avoid ABI breaks in released versions.

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

Glad to hear it- but realize that doing so *also* means an ABI break,
technically speaking.  Even if all you're doing is removing symbols that
people shouldn't be using, you need to treat it like any other ABI
break.

With regard to PostGIS, that probably means either living with 2.2.0
as-is for whatever your normal release timeframe is (or perhaps 6 months
as a minimum) and then putting out 2.3.0 w/ an ABI break, or doing a
real quick 2.2.1 with the change and more-or-less ask people to ignore
2.2.0.

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

We add things to libpq nearly every release- but those aren't
*backwards-incompatible* changes.

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

We are in the reasonably enviable position of not having had to actually
bump any of our symbol versions (since our last ABI break) and have
multiple versions work, as we try quite hard to avoid ABI breaks.
Remember- adding a symbol isn't an issue, it's just changing an existing
one that is an issue.

You can review the symbol versions of various libraries using

objdump -T /path/to/.so.

You'll quickly notice that lots of libraries today are using symbol
versioning.  I'm not sure how much of that usage is due to actual
changes vs. just giving new symbols the version of the first release
they showed up in (which isn't necessary but also doesn't really hurt
anything).

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

Ah, yes, I have some recollection of that now. :)

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

Happy to help.

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/87975889/attachment.sig>