Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jun 2002 22:55:23 +0100
From:      Nik Clayton <nik@freebsd.org>
To:        arch@freebsd.org
Subject:   Timetables for interface deprecation/deletion
Message-ID:  <20020618225523.J52976@canyon.nothing-going-on.org>

next in thread | raw e-mail | index | archive | help

--hABqaeELJqnDDeDE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[ 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'. =20

    * 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=20
    			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=
=20
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=20
  should be grounds for removal of a commit bit.=20
 =20
  Harsh, I know.  But as I mention above, we don't have a Linus-like
  figure to lay down the law. ]

N
--=20
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 ---         .\._/=
_)

--hABqaeELJqnDDeDE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE9D6xKk6gHZCw343URAoVwAKCQx2W9lRFkU77e4cRxHF/lJQ3DBwCfcxc+
+w6nhphALy3EMZ07778VI2E=
=LpCz
-----END PGP SIGNATURE-----

--hABqaeELJqnDDeDE--

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?20020618225523.J52976>