[ 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
* Library APIs
* The behaviour of command line options
* The use of certain commands
* Configuration options and mechanisms
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
Deprecated The interface is supported, but is slated for
obsolecence in the next major release of
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. ]