[OpenAFS-devel] open issues for an openafs 1.8 branch
Garrett Wollman
wollman@csail.mit.edu
Mon, 29 Sep 2014 19:04:57 -0400
<<On Mon, 29 Sep 2014 12:08:07 -0400, chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> said:
> Has OpenAFS ever been installed with shared libraries by any of the
> packaged installers? If not, I don't see a reason to bump the
> numbers. That said, if the API is changed (and changed in a
> non-backward compat way) we of course need to bump the numbers. I
> would comment that adding a symbol is changing the API and seems like
> it should require an increment.
No. That's not how ELF version numbers work. An ELF shared library
version number should never be changed except when an existing symbol
is either redefined (in a way that breaks binary compatibility) or
removed. And in either case, you should be using symbol versioning so
that they shared library version still doesn't change.
This is demonstrably difficult for a project the size of OpenAFS to
accomplish; a seemingly minor change to a type or a function's
signature may break binary compatibility in non-obvious ways. But
that's how it's supposed to work, in any event.
-GAWollman