[ 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