Date: Mon, 24 Jun 2002 01:25:49 +0100 From: Brian Somers <brian@Awfulhak.org> To: Nik Clayton <nik@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Timetables for interface deprecation/deletion Message-ID: <20020624012549.4ac2ee7b.brian@Awfulhak.org> In-Reply-To: <20020618225523.J52976@canyon.nothing-going-on.org> References: <20020618225523.J52976@canyon.nothing-going-on.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I think this sort of approach is good. We should introduce this sort of thing (as a section in our man pages), but (as Poul-Henning says) we shouldn't let it prevail against common sense. Interfaces such as those that ps(1) and the like use should have a classification of ``private'', meaning that you're not allowed to use it - even if it's documented (which it generally shouldn't be). However the stuff in places like libutil should be documented to a degree that people know whether they should use them or not. I don't think a major release number's worth of support is too much to ask for. In fact I'd say this sort of thing should be a major consideration for any commercial body deciding to go with FreeBSD. On Tue, 18 Jun 2002 22:55:23 +0100, 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 --- .\._/_) > -- Brian <brian@Awfulhak.org> <brian.somers@sun.com> <http://www.Awfulhak.org>; <brian@[uk.]FreeBSD.org> Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org> 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?20020624012549.4ac2ee7b.brian>