From owner-freebsd-hackers Wed Apr 19 23:54:02 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA20473 for hackers-outgoing; Wed, 19 Apr 1995 23:54:02 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA20446 for ; Wed, 19 Apr 1995 23:53:44 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA13641; Thu, 20 Apr 1995 08:53:08 +0200 Received: by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA14427 for freebsd-hackers@freebsd.org; Thu, 20 Apr 1995 08:53:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA02111 for freebsd-hackers@freebsd.org; Thu, 20 Apr 1995 08:49:46 +0200 From: J Wunsch Message-Id: <199504200649.IAA02111@uriah.heep.sax.de> Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley. To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) Date: Thu, 20 Apr 1995 08:49:46 +0200 (MET DST) Reply-To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) In-Reply-To: <199504200012.UAA07776@hda.com> from "Peter Dufault" at Apr 19, 95 08:12:06 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1096 Sender: hackers-owner@FreeBSD.org Precedence: bulk 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. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)