GSSAPI library compatibility between MIT releases

[Sam Hartman]

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:

    Cesar> I was wondering if someone from MIT can make a statement
    Cesar> regarding library/binary compatibility from one release to
    Cesar> the next of the GSSAPI libraries - I won't ask about
    Cesar> libkrb5 and related libs.

To my knowledge, MIT has not broken ABI compatibility since before
1.2.0 for libkrb5, libk5crypto, or libgssapi_krb5 on Unix.  We have
not broken ABI compatibility since KFM 4.5 or KFW 2.5.  I actually
believe the constraints for KFW and KFM are much wider than that, but
I know those are true.


We've decided that the public API (what you get from krb5.h, gssapi.h
and gssapi_krb5.h with no special macros defined) in 1.3 is stable.
We may deprecate portions of this API and we may add new APIs.  When
we deprecate portions of the API, we may require small source code
changes to get to prototypes and types defined by these portions of the API.  We have added new APIs in point releases.

We don't guarantee any level of support for features introduced in
development releases, alphas or betas until they make it into a stable
release.  


We have several people shipping our product who are depending on us
not breaking our ABI compatibility.  So if we were to drop an API we'd
almost certainly need a backward compatibility layer.  We'd start
talking about breaking the ABI when there was a clear need to change
functionality and the old functionality could not be expressed in
terms of new functionality.  That seems unlikely.  I think we may get
rid of krb4 before that happens.

So, there aren't really any rules about what release number changes
might imply an ABI breakage.  If we even start talking about an ABI
breakage without some backward compatibility, you'll hear a long
discussion here.

That said, our efforts to make the ABI stable may not be enough.  You
need to look at the stability of all the libraries that you link
against directly or indirectly when you pull in Kerberos.  If those
don't have particularly stable ABIs, they may create problems for
running old Kerberos applications.