From owner-freebsd-hackers Fri Apr 21 08:43:37 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA09771 for hackers-outgoing; Fri, 21 Apr 1995 08:43:37 -0700 Received: from redbird.cc.purdue.edu (redbird.cc.purdue.edu [128.210.7.32]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA09765 for ; Fri, 21 Apr 1995 08:43:34 -0700 Received: from localhost by redbird.cc.purdue.edu (8.6.10/Purdue_CC) id KAA25380; Fri, 21 Apr 1995 10:43:25 -0500 Message-Id: <199504211543.KAA25380@redbird.cc.purdue.edu> X-Mailer: exmh version 1.6gamma 3/31/95 To: hackers@FreeBSD.org Subject: Re: Release stability (fwd) In-reply-to: Your message of "Fri, 21 Apr 1995 00:34:55 MST." <2448.798449695@freefall.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Apr 1995 10:43:24 -0500 From: Bill Bormann Sender: hackers-owner@FreeBSD.org Precedence: bulk > > In the old DEC world there was a three piece cycle that was followed > > many times. A feature release followed by a robustness release. There > > was also a performance release that followed the robustness release. > > > > The focus was shifted during each release to concentrate on the > > primary goal of that release. Customers knew what to expect in > > general terms. > > > > We seem to be trying to do all three simultaneously and I don't think > > its really possible to do. > > This is about the best general summary of the situation I've seen yet. > > Yes, I think that a new/stable/fast cycle of 3 has a lot to be said > for it. What would people say to us going to the following numbering > scheme in support of this? > > .<0,1,2[,3..]>[.] > > Where a bump in would signal a fairly major paradigm shift of > some sort, the 0 release for which would be the "features" release. > It wouldn't be guaranteed not to eat you and your entire family for > breakfast, it would be for the rocket jockeys who enjoy riding out on > the bleeding edge. The .1 release would be the fixed version of the > .0 and for the more staid sorts. The .2 release would be the final > stage of evolution with things sped up and generally made to work > "optimally", for whatever the value of optimum might be. > > If we needed snapshots, those would trail between in the "100's place" > with things like 2.0.1 or 2.1.2 being valid and reasonable snapshot > names (the 1st post-2.0 snapshot and 2nd post-2.1 snapshots, > respectively). > > This would also remove Garrett's objection to date-based snapshot > names. I could be more than happy with a release numbering scheme > (and underlying philosophy) like this. What say the rest of you? > > Jordan I like this idea. I am still running 1.1.5.1, having deliberately skipped the 2.0 release because I was not convinced 2.0 would be as stable as the its predecessor. Maybe the easiest way to answer these questions is to think about who is running FreeBSD and then tailor your releases for that audience. I think the program Jordon proposes would certainly meet my needs. I will explain why. I write client server applications and do routine system maintenance on a variety of operating systems. During my career I've worked on (probably) a dozen different operating systems (MVS, RSTS/E, VM, Unix, MS-DOS, Windows, etc.), so I've seen just about everything out there. I tend to look at any OS from a detached, dispassionate frame of mind. My priorities are reliability, comfort ("ease of use"), and performance. I tried doing my job running Windows 3.1. Windows was too unstable and too inefficient; a crash every two or three days may be ok for Microsoft, but I found it too annoying. FreeBSD (with XFree) provides the best work environment I have ever experienced. Even though I am no Unix guru, FreeBSD was easy to install, easy to configure, and easy to upgrade. It has been a simple matter to add packages as I needed them. But, I have to be careful. Management here, like management everywhere, is suspicious of anything free, because they believe that free software indirectly sucks dollars out of their pocket by diverting intellectual resources into bug fix and support for the free package. I don't dare upgrade without monitoring the hackers and questions list for FreeBSD, because I have to be very well informed about what you are doing and what problems I should expect before I walk the upgrade plank. There are probably a few people who run FreeBSD in the same situation. For me to know the x.1 and x.2 versions have certain target standards adds that important "warm fuzzy feeling" and simplifies my decision process about upgrading my system. Bill Bormann ad2@cc.purdue.edu (Internet) | Purdue University Computing Center | 1408 Mathematical Sciences Building | West Lafayette, IN 47907-1408