At 7:24 PM +0100 6/5/02, Brian Somers wrote:

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.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message