Date: Wed, 01 Nov 1995 22:08:08 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Chuck Robey <chuckr@glue.umd.edu> Cc: -Vince- <vince@apollo.COSC.GOV>, Ollivier Robert <roberto@keltia.freenix.fr>, julian@ref.tfs.com, jc@irbs.com, current@FreeBSD.org, FAQ@FreeBSD.org Subject: Re: FreeBSD 2.1 update Message-ID: <20042.815292488@time.cdrom.com> In-Reply-To: Your message of "Wed, 01 Nov 1995 23:16:53 EST." <Pine.SUN.3.91.951101231224.26683A-100000@latte.eng.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Maybe that's right, but it's not what I understood to be true. Understand > that this stuff is not written in stone, there are no contracts forcing > things to happen in any particular manner, but I had the understanding > that we were going to be doing a dual-track thing. The even numbered The problem is that the dual-track thing is turning into a LOT of work, and I don't think that David is entirely amused at the amount of life he's lost in keeping things in sync.. What will no doubt evolve is something more "holistic" where we maintain the 2.1 release branch as long as it seems practical to do so (e.g. as long as it makes sense to continue releasing bug-fix point releases along it) and beaver away in 2.2 as the catch-all experiemental branch. At some stage, I'd hope that 2.2 would slow down enough to become stable, at which point (perhaps just short of the point of most ideal stability) maybe we'll just branch again and let 2.2 become what 2.1 is now, with 2.3 becoming -current. I don't know though, we could end up doing something entirely different than this. This is one of those things that's really difficult to do advance planning for in a volunteer effort. Sometimes we move really fast, other times we slow to a crawl. Sometimes we fix something really critical and we'd really like to see it in a release, other times we break the tree pretty badly for awhile with a new experimental feature that eventually turns out to be worth the effort but is a pain in the butt during the transition period. I do know that we have very finite engineering resources, and we need to apply them in the most cost-effective manner or we will simply cease to exist. Striking a balance between this and what the users want is the challenge we'll be facing over the next 12 months or so, and this will effect how the releases are numbered and planned. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20042.815292488>