Date: Thu, 20 Apr 1995 04:30:52 -0700 From: Edward Wang <edward@edcom.com> To: freebsd-hackers@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley. Message-ID: <199504201130.EAA00500@edcom.com>
next in thread | raw e-mail | index | archive | help
/ Hmm, it's perhaps a question of naming. I think the Berkeley / tradition was to have even-numbered releases with lots of new stuff / and odd-numbered releases which have been mainly bugfix releases. / (I dunno if this has been intention or not.) Nah. 4.1c, for example, was the first with most of the goodies. Unless you don't count the lettered releases. My impression was that funding and personpower (I'm from Berkeley after all) pretty much dictated what happened after 4.1c. Mind you, I wasn't in the thick of things, I just hung out there. / However, _every_ release should be of some basic quality that's better / than say the average ***x release quality. We all know about 2.0, but / it should remain an exception. Yeah, what makes our job for 2.1 so / hard is the fact that 1.1.5.1 was of such a quality that it beats many / commercial systems -- and we want to have 2.1 at least as stable as / 1.1.5.1. 1.1.5.1 was a fantastically stable release. Maybe the thing is to have a feature freeze (if there isn't already such a thing), say at the April SNAP level, and concentrate on pounding on the thing. This complicates the management of the source tree though. So maybe the thing to do is to have a clear demarcation of what's experimental and what's solidly tested and supported. Users can be warned off the experimental bits if they prefer stability over feature. The man pages already try to do this, but the boundary should be clearer. Mainly, we don't want to imitate the Linux I-wrote-this-and-now- you-try-it-out style. I'm not on the core team, so I should shut up now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504201130.EAA00500>