VERSION vs. SOVERSION

[nschloe]

This is more of a request for clarification.

In a typical unix project, versioning works such that the major revision number indicates the A{B,P}I level of the library, and consequently works as SOVERSION. When looking into /usr/lib/, you will find almost exclusively the scheme

$ ls -l /usr/lib/libpathplan.*
/usr/lib/libpathplan.so.4 -> libpathplan.so.4.0.0
/usr/lib/libpathplan.so.4.0.0

(I have no idea what "pathplan" is, it merely serves as an example here.)

For netCDF, things appear to work a little differently. The software version will soon be 4.3.2, and the SOVERSION is set to 7.2.0. Is that by mistake, for historical reasons, and are there plans to go with the mainstream flow?

[WardF]

On 3/20/14, 6:27 AM, Nico Schlömer wrote:

This is more of a request for clarification.

In a typical unix project, versioning works such that the major
revision number indicates the A{B,P}I level of the library, and
consequently works as SOVERSION. When looking into |/usr/lib/|, you
will find almost exclusively the scheme

|$ ls -l /usr/lib/libpathplan.*
/usr/lib/libpathplan.so.4 -> libpathplan.so.4.0.0
/usr/lib/libpathplan.so.4.0.0
|

(I have no idea what "pathplan" is, it merely serves as an example here.)

For netCDF, things appear to work a little differently. The software
version will soon be 4.3.2, and the SOVERSION is set to 7.2.0. Is that
by mistake, for historical reasons, and are there plans to go with the
mainstream flow?

—
Reply to this email directly or view it on GitHub
#42.

Russ will correct me if I'm wrong, but I don't believe there will be any
move to sync VERSION and SOVERSION.

SOVERSION typically acts to indicate API compatibility; if a software
version is incremented but no change to the API is made, it would be
inappropriate to modify the SOVERSION. This makes it easier to
determine binary compatibility between libraries. I won't contest that
there exist many projects that use the VERSION and SOVERSION
interchangeably, but I would argue that they are using the SOVERSION
property incorrectly :).

That said, I'm not sure why the SOVERSION is 7.x while the netcdf
version is only 4.x. Perhaps Russ can clarify.

-Ward

[nschloe]

Indeed!
I'll try to clarify what I stated above: I believe that the vast majority of unix projects go one step further and bump their major revision number whenever the API changes. This makes is possible for dependent projects to say "Our software works with WhateverLib 4.*". If the version is x.y.z, the SOVERSION would be x.
In netCDF, the major revision number seems to be entirely decoupled from the SOVERSION. Also, unusually, the SOVERSION has a major, a minor, and a patch version ("7.2.0"). These are the two things that make it look a little weird.

[russrew]

There's no need to keep the shared-object version and the package version in sync. We try to follow the guidelines here: http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html
In particular, note this excerpt:

Never try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release.

I think the reason our major soversion is 7 is due to adding and fixing several interfaces in the C API early in the development of netCDF-4.

[nschloe]

There's no need to keep the shared-object version and the package version in sync.

There is no need of course, the current state is absolutely lega; it wiykd just make things more obvious. After all, a user of netCDF is not so much interested if the release version is 3.6 or 4.1, it's really the A{B,P}I version (aka the "interface number") that is important (currently 7.2.0). Without a connection between them, the release version is really just a vague indicator of "progress" (which may or may not be the case for netCDF right now).

Anyways, this just struck me as an oddity of netCDF.

[WardF]

I'm going to close this out but am leaving a bookmark to it as an issue to consider in the future. There is no immediate move to the change Nico has suggested, but it is something to keep in mind as we move forward.