From owner-freebsd-arch Tue Jun 18 18:20:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 8241A37B40A; Tue, 18 Jun 2002 18:19:56 -0700 (PDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g5J1Jtk20161; Tue, 18 Jun 2002 18:19:56 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 18 Jun 2002 18:19:55 -0700 Received: from twogun.apple.com (twogun.apple.com [17.202.45.118]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g5J1Jri10871; Tue, 18 Jun 2002 18:19:54 -0700 (PDT) Date: Tue, 18 Jun 2002 18:19:51 -0700 Subject: Re: Timetables for interface deprecation/deletion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v524) Cc: arch@FreeBSD.ORG To: Nik Clayton From: "Jordan K. Hubbard" In-Reply-To: <20020618225523.J52976@canyon.nothing-going-on.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.524) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 --- > .\._/_) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message