Date: Thu, 20 Apr 1995 07:05:04 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: freebsd-hackers@FreeBSD.org Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley. Message-ID: <199504201105.HAA09709@hda.com> In-Reply-To: <199504200649.IAA02111@uriah.heep.sax.de> from "J Wunsch" at Apr 20, 95 08:49:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch writes: > > As Peter Dufault wrote: > > > > > > We should look at X.Y.Z releases every N months (3?) (2.5?) > > > > > > I think, 3 months have been the initial intent of WC for regular > > > releases... > > > > I think 6 month releases with 3 month bug fix releases (4 releases > > per year) would be great and almost impossible to actually do, and > > would be a good target. > > 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.) > > 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. No, it wasn't a question of naming. I don't believe we could actually produce 4 releases a year that are worth producing. I propose what Nate thought I proposed: two real releases per year, with branches off the release where critical bug fixes were put, and if there were enough critical bug fixes a bug fix release as in 2.0.5. When there are no bugs and not enough value added new non-kernel stuff, then skip the bug fix release. 2.0 : Release 2.0.? : Bug fix release 2.1 : Release 2.1.? : Bug fixes. Yes, it is more of a headache but are there that many critical bug fixes (outside of for 2.0) that we are applying that many fixes to the branch? If there are then the releases are being pushed out without adequate test. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504201105.HAA09709>