From owner-freebsd-chat Tue Jun 27 12:19:42 2000 Delivered-To: freebsd-chat@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id 98F2937C1F3 for ; Tue, 27 Jun 2000 12:19:37 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA27836; Tue, 27 Jun 2000 13:19:07 -0600 (MDT) Message-Id: <4.3.2.7.2.20000627131107.0449d500@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jun 2000 13:18:59 -0600 To: Brooks Davis , Francisco Reyes From: Brett Glass Subject: Re: Why can't upgrades be simpler? Cc: FreeBSd Chat list In-Reply-To: <20000626232045.A17065@orion.ac.hmc.edu> References: <200006270352.XAA29208@sanson.reyes.somos.net> <200006270352.XAA29208@sanson.reyes.somos.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:20 AM 6/27/2000, Brooks Davis wrote: >I think the problem is likely one of perception. One might think that >there is a logical progression of little steps as follows: > >3.0 -> 3.1 -> ... -> 3.4 -> 4.0 > >The problem is that it's actually more like this: > >3.0 -> 3.1 -> ... -> 3.4 -> 3.5 > \ > \ > \ > -------------> 4.0 > >What you have is two diverting streams of development starting the >day the previous .0 release ships[0]. While many changes are merged >back to the previous branch (or sometimes even further[1]), there are >inevtiably things which are simply too major to merge into -STABLE. This is one of the things about the FreeBSD development methodology with which I (and others!) have long taken issue. Since ".0" versions are usually described as "experimental," and often have glitches that make it unwise to deploy them in production environments, the branching should occur later. Instead of creating a new (N+1).0 branch as soon as N.0 ships, one should wait for branch N to achieve full production quality. Thus, (N+1).0 should probably start with the code from version N.2. The result would look like this: 3.0 -> 3.1 -> 3.2 -> ... -> 3.4 -> 3.5 -> ... -> 3.8 \ \ \ ---------------> 4.0 This would ensure that new versions would be built on a firmer foundation and that more effort went into maintaining rock-solid versions of the OS while new branches were perfected. It would also reduce the effort invested in backporting and would shorten the period of time for which a previous version needed to be maintained. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message