From owner-freebsd-stable@FreeBSD.ORG Sun Sep 21 01:02:28 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 E310E1065670; Sun, 21 Sep 2008 01:02:27 +0000 (UTC) (envelope-from netgeek@bgp4.net) Received: from mail.bgp4.net (mail.bgp4.net [64.247.24.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB0B8FC14; Sun, 21 Sep 2008 01:02:27 +0000 (UTC) (envelope-from netgeek@bgp4.net) Received: from janet-sullivans-macbook-pro.local (pool-71-112-183-31.sttlwa.dsl-w.verizon.net [71.112.183.31]) (authenticated bits=0) by mail.bgp4.net (8.14.2/8.14.2) with ESMTP id m8L0bV2Z004953 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 17:37:37 -0700 (PDT) (envelope-from netgeek@bgp4.net) Message-ID: <48D596AD.1070209@bgp4.net> Date: Sat, 20 Sep 2008 17:34:53 -0700 From: netgeek User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Robert Watson 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.bgp4.net [64.247.24.57]); Sat, 20 Sep 2008 17:37:38 -0700 (PDT) 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 01:02:28 -0000 Robert Watson wrote: > When it comes to commercial OS products, like Windows and Mac OS X, > there is often a strict requirement to live on the most recent minor > release in order to continue to receive support. For example, you won't > make a lot of headway turning up at Apple and demanding security updates > for Mac OS X 10.5.0 a year after it has been released. The answer will > be "Great, update 10.5.3" (or something along those lines) -- not only > will it fix the security issues, but it will support the hardware we now > sell. In that sense, we're actually quite different: rather than saying > "Sorry, 6.2 is vulnerable, please upgrade to 6.3", we say "You can live > on 6.2 for up to 18 months and receive *only* security and critical > errata patches". > > 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. I really wouldn't mind being told to upgrade from 7.2 to 7.4_p12 because its been 20 months since the last 7.x release. Because companies are used to the Apple and Microsoft way you outlined above, I don't think they'd have a huge problem with it either. Wouldn't it make it easier on the teams to only ofter extended support for the major versions, rather than trying to support specific minor versions (6.3, 6.4, 7.0, 7.1) for an extended time? I'll admit, in the early days of 5.x, I really didn't like having to jump between minor versions. Let's face it, things didn't really settle down until, what, 5.3? In those days, being able to stay on a specific minor release was a Good Thing. However, I don't have the same kind of API and upgrade fear going from 6.x to 6.y. Maybe there are people out there who truly fear upgrading from 6.3 to 6.4, and need both supported for an extended time. But if resources are limited, it seems that only offering extended support for the latest release from a major branch would be the way to go. Perhaps 6-12 months for a minor release, 24+ months for the entire major release train? I'm not demanding anything, or saying this is the right way. I'm just wondering if there is a compromise out there that would give companies the security that their 6.x or 7.x server will have 2 years+ of support for vulnerabilities, while at the same time not requiring the developers to extended support for multiple minor releases. I'll now go put on my asbestos undergarments and sit in the corner. ;-)