From owner-freebsd-arch Wed Jun 5 14:37:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 65FD737B400 for ; Wed, 5 Jun 2002 14:37:28 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g55LbOeK069840; Wed, 5 Jun 2002 17:37:25 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020605192430.1f29c8d2.brian@Awfulhak.org> References: <200206050051.UAA07971@renown.cnchost.com> <20020605192430.1f29c8d2.brian@Awfulhak.org> Date: Wed, 5 Jun 2002 17:37:23 -0400 To: Brian Somers From: Garance A Drosihn Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:24 PM +0100 6/5/02, Brian Somers wrote: >On Tue, 4 Jun 2002, Garance A Drosihn wrote: > > Aside: I would also say that I feel that "two major releases" >> might be a bit too painful for changes in the freebsd project, > > if you're talking about major releases being 3.0 vs 4.0. > >A company that develops software doesn't expect to have to >employ software engineers (to redevelop their software) for >an OS upgrade - an OS upgrade that we're essentially forcing >on them because of our frequent releases and our inability >to support all but the latest of those releases. I agree that we could do a better job of smoothing in the transition of some incompatible changes. But it is my feeling that "major releases" are probably not the best way to set the timescale for those transitions. 2.0 -> 3.0 took four years, 3.0 -> 4.0 took a little less than two years, and it looks like 4.0 -> 5.0 will take more than two and a half years. That rule would imply that if we decide right now to make an incompatible change, then we couldn't stop supporting "the old way" for at least four years (ie, for two major releases). I agree would be very fine thing to do for our users, but realistically I think that is *much* too big a job for us (as a project) to commit to. I am not sure what a good measure would be. Maybe "four official releases" (ie, four of the .1 releases). Maybe "one major and one minor release". Maybe just "two years worth of releases". I don't know what would work best. But we should set it to something that we really can achieve as a volunteer project, and something we would expect to apply to the *entire* project, consistently. There isn't any point in setting some target which sounds good as a marketting claim, but which we would never actually live up to. Note that as a customer of freebsd, the oldest release I have running in production is 4.2, and I'm getting uneasy about how old that is. As a developer, I also have a 3.5.1 system that I can boot up in vmware. If you talk about supporting anything older than that, then you've crossed the line for how much work I'm willing to do for this project. Well, I've probably rambled on too long about this, without really coming up with any good solution. Just some observations and my opinions. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message