Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jun 2002 18:19:51 -0700
From:      "Jordan K. Hubbard" <jkh@apple.com>
To:        Nik Clayton <nik@FreeBSD.ORG>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Timetables for interface deprecation/deletion
Message-ID:  <A73CF92E-8322-11D6-9FE9-000393038CC8@apple.com>
In-Reply-To: <20020618225523.J52976@canyon.nothing-going-on.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Nik,

I'm glad you were the first one to bring this up since I'd likely have 
only been accused of being self-serving if I were the one to do so. :-)

Apple is facing the very same issue with respect to "published APIs" 
and making it clear which we're free to deprecate at some future date, 
which are obsolete and purely for backwards compatibility (e.g. not to 
be used for new code), which are purely "use at your own risk" and 
which are fully supported in the sense that we'll contort ourselves 
into all sorts of unnatural shapes, if and as necessary, to preserve 
compatibility with them.

We've also adopted Sun's nomenclature for the macros which bracket 
these APIs in various headers since we didn't see any need to reinvent 
that particular wheel.  I don't have the list handy right now, but it 
basically defines the macro names you need to bracket the various 
header definitions for the APIs you want to classify and/or restrict.  
If FreeBSD's willing to go the same route, it would greatly help in 
syncronizing this kind of API clean-up work between FreeBSD and Darwin. 
  Thoughts?  I'm just looking for opinions at this stage and nobody's 
talking about touching ANYTHING right now, this is just stage 1 (or 
zero, depending on how you measure things).

- Jordan

On Tuesday, Jun 18, 2002, at 14:55 America/Los_Angeles, Nik Clayton 
wrote:

> [ It's times like this I regret the fact that we don't have a Linus
>   equivalent to lay down the law ]
>
> As FreeBSD develops, we inevitably change, adapt, and throw away old
> 'interfaces'.
>
>     * Library APIs
>     * The behaviour of command line options
>     * The use of certain commands
>     * Configuration options and mechanisms
>
> and more.
>
> I think the life cycle of an interface can be described as follows:
>
>     Introductory	We make no guarantee this interface will be in
>     			future versions of FreeBSD.
>
>     Stable		This interface is guaranteed to exist in
>     			all minor versions of FreeBSD corresponding with
> 			the major version in which it exists.
>
> 			Once an interface is marked 'Stable' it must go
> 			through the 'Deprecated' and 'Obsolete' stages
> 			before removal.
>
>     Deprecated		The interface is supported, but is slated for
>     			obsolecence in the next major release of
> 			FreeBSD.
>
>     Obsolete		The interface is not supported.  It may work,
>     			but it is not guaranteed to.  The interface will
> 			be removed in the next major version of FreeBSD.
>
> Assuming, for the moment, that that makes sense to people, over what 
> sort
> of timescales should interfaces move from state to state?
>
> And does the project have the will to guarantee this?
>
> [ "Guarantee"?  OK, nothing's guaranteed in an open source project.  
> But
>   IMHO, there are a few things that the project should commit to.  As
>   long as these things are appropriately documented, and decided upon 
> --
>   committer vote?  core declaration? -- unwillingness to commit to them
>   should be grounds for removal of a commit bit.
>
>   Harsh, I know.  But as I mention above, we don't have a Linus-like
>   figure to lay down the law. ]
>
> N
> -- 
> FreeBSD: The Power to Serve      http://www.freebsd.org/               
> (__)
> FreeBSD Documentation Project    http://www.freebsd.org/docproj/    
> \\\'',)
>                                                                       
> \/  \ ^
>    --- 15B8 3FFC DDB4 34B0 AA5F  94B7 93A8 0764 2C37 E375 ---         
> .\._/_)
> <mime-attachment>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A73CF92E-8322-11D6-9FE9-000393038CC8>