From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 08:57:57 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 13AD81065675 for ; Sun, 21 Sep 2008 08:57:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D2CDB8FC87 for ; Sun, 21 Sep 2008 08:57:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 03DEC46C1C; Sun, 21 Sep 2008 04:57:53 -0400 (EDT) Date: Sun, 21 Sep 2008 09:57:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: netgeek In-Reply-To: <48D596AD.1070209@bgp4.net> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <48D596AD.1070209@bgp4.net> 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 , Lowell Gilbert 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: Sun, 21 Sep 2008 08:57:57 -0000 On Sat, 20 Sep 2008, netgeek wrote: >> Don't get me wrong: I would love to see us support all releases for 24 >> months (or even more) after they ship. I think our users would appreciate >> that also. > > Perhaps there is a middle ground here? What about a statement that each > major branch (6.x, 7.x) will be supported for at least 24+ months from its > last production release? Smaller periods of support could be given to minor > releases along the way (7.2, for example), but at least companies would know > that if they installed a 6.x version, they'd have support for a couple of > years, even if that might mean upgrading to a newer minor version if there > was a problem. This is precisely what we already do -- we guarantee we will support the last release on a branch for 24 months after the release. The point of concern being discussed is that we can't tell you for sure which minor release will be the last release at the time that release goes out the door, because the extent to which we keep releasing on old branches depends in large part on how the new branch looks. Right now, it sounds like 6.4 will be the last minor release on the 6.x branch, but I think it would be a mistake to commit to that decision until 7.1 has settled in for a few months and we believe firmly there is a good migration path forwards to the 7.x branch. 7.0 was arguably one of the most stable .0 releases we've ever done (perhaps the most stable -- 4.0 was pretty good though), so it seem almost certain 7.1 will be really stable, but stable is what happens when people install it and it works well in practice, so there's always a wait-and-see element. Robert N M Watson Computer Laboratory University of Cambridge