GSSAPI library compatibility between MIT releases
Cesar.Garcia at morganstanley.com
Tue Jan 27 07:50:20 EST 2004
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> 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).
More information about the krbdev