From owner-freebsd-current Sun Sep 17 13:19:30 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA24720 for current-outgoing; Sun, 17 Sep 1995 13:19:30 -0700 Received: from localhost.lightside.com (user44.lightside.com [198.81.209.44]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA24715 for ; Sun, 17 Sep 1995 13:19:25 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id NAA00185; Sun, 17 Sep 1995 13:19:58 -0700 Date: Sun, 17 Sep 1995 13:19:33 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: jdl@chromatic.com cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: Release numbering In-Reply-To: <199509170528.AAA14969@chrome.onramp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sun, 17 Sep 1995, Jon Loeliger wrote: > Apparently, "Jordan K. Hubbard" scribbled: > > The only serious question still to be resolved is just when the > > "rollover" happens? Does 2.1.x live forever, or does it get abandoned > > with 2.2.x is "stable?" > > Personally, I think trying to maintain a strict 2.1 derived base for > a very long time will become fairly problematic. You'll likely end > up with the nightmare of figuring out which variant of which patch > gets applied to which branches and the resulting rev interlock. > Been there done that. Wasn't too much fun then either. > I agree here. Release bug fixes for 2.1.x if something drastic comes up, but as soon as 2.2 becomes as stable as 2.1, push it out the door as a release and start thinking about 2.3. > > > Does 2.1 just become 2.3 at some point, > > leaving the odd numbered releases as the "stable" ones and the even > > numbered ones as "experimental?" > > Isn't that what the makers of the Star Trek movies decided to do? :-) > Oh wait, no. The odd ones sucked and the even ones were good, right? > > Yea, this is probably the basic approach to take. As soon as 2.1 goes > out the door, people are generally going to breath a huge sigh of > relief, take a break, and then be real gung-ho about 2.2. Why not > just let everyone work on 2.2 until it too gets to a reasonably > stable point and then call it "stable" at the same time introduce 2.3 > as the next development release. Just pipeline it, not leapfrog it? I completely agree. Leapfrogging releases a la Linux kernel, is too confusing. People are going to get 2.1, then see 2.2 on the FTP site, not realize it's 2.2-bleeding-edge-sig11, download it, and screw up their machines. I'd rather see a 2.2-current (even though I have ambivalent feelings about the name current to mean "bleeding edge"), that would slowly become 2.2-RELEASE, than a 2.2-current that became 2.3! > > In short, we may be digging ourselves a deep hole if we can't decide > > just how this is all going to work. > > Agreed. Other than the name "current" being a little confusing, the release schedule as it exists now is just fine. But trying to maintain three or four different simultaneous release trees is going to be hell. Having a -stable and a -current is a good idea now, but when 2.1.0 is finally released, we may be able to get away with just a -RELEASE and -current, which would sure save effore integrating changes from -current back into -stable. ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------