From owner-freebsd-stable@FreeBSD.ORG Sat Sep 6 11:06:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 065781065672 for ; Sat, 6 Sep 2008 11:06:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B0B6A8FC1C for ; Sat, 6 Sep 2008 11:06:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 80F5946B42; Sat, 6 Sep 2008 07:06:11 -0400 (EDT) Date: Sat, 6 Sep 2008 12:06:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ben Kaduk In-Reply-To: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jo Rhett , freebsd-stable , Wesley Shields , Nathan Way Subject: Re: Upcoming Releases Schedule... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 11:06:14 -0000 On Fri, 5 Sep 2008, Ben Kaduk wrote: > To quote from the same website: > Early adopter > Releases which are published from the -CURRENT branch will be > supported by the Security Officer for a minimum of 6 months after the > release. > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after the > release. > Extended > Selected releases will be supported by the Security Officer for a > minimum of 24 months after the release. > > I don't remember seeing any speculation about 6.4 being an extended release, > so, EoL is 12 months after release, whenever that actually happens. Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release (i.e., general perception of stability and performance), but also based on the success of other simultaneously releasing branches. We normally don't make a .0 release "extended support" because there's a reasonable expectation that .0 releases will see more limited deployment than, say, a .1 or .2 release, and that those incrementally later releases will be significantly more stable or performant as a resut of the burn-in the .0 received from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert N M Watson Computer Laboratory University of Cambridge > > I thought this was mentioned in the previous thread you started about EoL, > but I didn't see it in a quick search. > >>> The answer to that is not clear - >>> nor do I know if it should be clear yet. I don't know when the type of >>> support decision is made, but I suspect it's not this early in the >>> process. >> >> >> The release date for 6.4 is ~30 days away, isn't it? >> >> Also given that we've previously seen overlaps such that a newer version is >> only supported to the same EoL as the older version, that would pretty much >> dictate that spending resources on testing 6.4-REL and/or upgrading would be >> futile. >> > > That's the difference between a long-term-support branch and a regular branch; > many OSes do that. If you want to run the same machines for a long time and > not have to do a huge battery of tests (at the expense of getting new features > and better performance in the interim), you use long-term branches. > The regular branches that get released later, will then become unsupported > at the same time as the (older) long-term branch. > > Yes, it's poor when a long-term branch goes EoL before there's another one > ready to take its place, but if the new one isn't ready, then you just use > whichever regular release is current and then snag a long-term release > when it becomes available. Yes, it's more work, but that's life. > > -Ben Kaduk > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >