[2312] in Kerberos-V5-bugs
pending/76: Re: add API versioning before next release
daemon@ATHENA.MIT.EDU (tytso@MIT.EDU)
Sun Oct 6 20:37:13 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: gnats-admin@rt-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, tytso@MIT.EDU
Date: Sun, 6 Oct 1996 20:36:28 -0400
From: tytso@MIT.EDU
To: hartmans@MIT.EDU
Cc: krb5-bugs@MIT.EDU
In-Reply-To: <9610060532.AA17176@starkiller.MIT.EDU> (hartmans@MIT.EDU)
>Number: 76
>Category: pending
>Synopsis: Re: add API versioning before next release
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sun Oct e 20:37:00 EDT 1996
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
From: hartmans@MIT.EDU
Date: Sun, 6 Oct 1996 01:32:40 -0400
In short order, the Kerberos Team should decide whether it
will implement API versioning and if it should do so, decide how to
maintain compatability with Beta 7 while allowing for future
extensions.
API Versioning is utterly trivial to do, and we can even do it without
breaking compatibility with Beta 7.
The simple way (which will break compatiiblity), is to change
krb5_init_context() to take an extra argument, which is the API version
number.
And the way to solve the Beta7 compatibility issue is to simply *add* a
new function, krb5_api_version(context, version_number), which allows
the application to declare what version of the API it is expecting.
See? Not hard. And we don't need to do anything now, if we wish to add
it later. (Just assume tht if krb5_api_version() is not called, that it
is the "1.0" version of the API.)
- Ted
