[postgis-users] Ugly Library Naming Realization

Paul Ramsey pramsey at refractions.net
Fri Jun 28 09:08:59 PDT 2002


I was just pondering a 0.7.2 release, and thinking favourably about the
fact that since the library would not change numbering, it would be a
very easy upgrade (just copy over the old .so file). It was at that
point that I realized that we had put our users through several
unnecessary upgrades via our arbitrary linking of the library numbering
scheme to our version numbering scheme. 

Here is the deal for people with libraries: You should only change the
major number of your library if you are breaking binary compatibility.
Right now, our postgis.sql points to the fully qualified name of the
library, so any change in the number will break references loaded into
the database. We could change that so that we just point to the
symlinked major name of the library (libpostgis.so.0 for example instead
of libpostgis.so.0.7) That way we could increment the minor number
whenever we liked without breaking peoples installs. 

That is all well and good, but the second problem is the connection
between the version numbering and the library numbering. We increment
versioning somewhat arbitrarily as we feel we have added significant
functionality, which may not actually break binary compatibility,
heading towards the goal of SFSQL compliance at version 1.0. We could
break the link between library numbering and version numbering, but
people might find that confusing. Or we could just slave our numbering
to the library. Increment minor when we do a new release without binary
breakage, increment major when we do have binary breakage.

I wonder what others think.

P.




More information about the postgis-users mailing list