GSSAPI library compatibility between MIT releases

[Cesar Garcia]

Thanks Sam - two more question (below)

>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

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

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

Considering statement in last paragraph below, does this then also
apply to lib_comerr?

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

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


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

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

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

One last question (which shows my ignorance on this subject), if I'm
always linking with a set of libraries from the *same* MIT release
(that is e.g., I don't mix 1.3.1 libgssapi_krb5 and 1.2.8 libkrb5) and
my app's only lib dependency is libgssapi_krb5 (and I only reference
symbols from libgssapi_krb5), need I worry about say an ABI change
to libkrb5 in such a case? (I would suspect not, but like I said, I'm
somewhat ignorant on this matter).

Thanks again.