Date: Wed, 5 Jun 2002 17:37:23 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Brian Somers <brian@Awfulhak.org> Cc: arch@FreeBSD.ORG Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) Message-ID: <p0511172cb92425b8c91d@[128.113.24.47]> In-Reply-To: <20020605192430.1f29c8d2.brian@Awfulhak.org> References: <200206050051.UAA07971@renown.cnchost.com> <p05111729b92324e697ef@[128.113.24.47]> <20020605192430.1f29c8d2.brian@Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:24 PM +0100 6/5/02, Brian Somers wrote: >On Tue, 4 Jun 2002, Garance A Drosihn <drosih@rpi.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0511172cb92425b8c91d>