From owner-freebsd-chat@FreeBSD.ORG Tue Jun 8 15:43:24 2010 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57ED7106566C for ; Tue, 8 Jun 2010 15:43:24 +0000 (UTC) (envelope-from emailrob@emailrob.com) Received: from mx01.dls.net (mx01.dls.net [216.145.245.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6FF8FC0C for ; Tue, 8 Jun 2010 15:43:23 +0000 (UTC) Received: from [216.145.235.42] (helo=emailrob.com) by mx01.dls.net with esmtp (Exim 4.69) (envelope-from ) id 1OM0xV-0005Jj-26; Tue, 08 Jun 2010 10:43:22 -0500 Message-ID: <4C0E5712.2000606@emailrob.com> Date: Tue, 08 Jun 2010 15:43:30 +0100 From: spellberg_robert User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: fbsd_chat References: <4C0A67E7.3080405@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [_fbsd_chat_] why the different eol lengths ? [ was: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 7.2 EoL coming soon ] X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 15:43:24 -0000 greetings --- i am putting this on _chat because it is more than a "question" and it has a tinge of "advocacy". let me say, straight_away, that i am not making any allegations or accusations; i am attempting to reason this through, deductively, and i am making little head_way. question: if version "x dot y_plus_one" is "better" [ for some definition of that word ] than version "x dot y", then why is support for the "better" version being terminated, by --design--, before support for the "less_than_better" version ? i just don't understand the "by design" part. i can understand longer support, by design, for the last version of a series [ e. g., 4.11, 5.5, 6.4, 7.3, et cetera ]; some people may like some characteristic [ of course, the last version --should-- have a long_date, by design, on general principle ]. i can understand shorter support, by design, for the zeroth version [ e. g., 5.0 ]; after all, it is, effectively, a "super_beta". i can understand, after_the_fact, extending an original end_of_life_date, due to the occurrence of some un_foreseen event. i suppose that some_one will "pipe_up" that this policy reduces the number of versions that are to be maintained; but, this argument has a flaw. in the sequence "long_date_a, short_date_b, long_date_c": if i am running "a", then why should i upgrade to "b"; if i am going to have to upgrade to "c", anyway ? i may_as_well wait for the release of "c", in the first_place. from this, it follows that there isn't much point in releasing "b" [ if many follow this reasoning, why bother ? ]. on the other hand, "b" could be announced as a "super_beta" for "c", i suppose; but, now, i have shifted from deduction to induction [ do i really want to go here ? ]. i have considered the possibility that my lack of understanding could result from my not being a "bleeding edge" type. i have rejected this argument because these people will always install the "latest_and_greatest" version nearly immediately; therefore, to them, the details of --any-- policy will be irrelevant. looking at the dates [ included below, for_your_ready_reference ], if a body is running 6.4, they may_as_well wait until the end of the year, so as to re_evaluate the situation, in light of the possible existence of 7.5, 8.3 and/or 9.1; right now, 7.3 is the only one that is worth the effort. i just don't "get it". rob FreeBSD Security Officer wrote: [snip] > Please note that since FreeBSD 7.1 > has been designated for 'Extended' support, it will continue to be supported > until the end of January 2011, i.e., FreeBSD 7.1 will be supported longer > than FreeBSD 7.2. [snip] > +---------------------------------------------------------------------+ > | Branch | Release | Type | Release date | Estimated EoL | > |-----------+------------+--------+-----------------+-----------------| > |RELENG_6 |n/a |n/a |n/a |November 30, 2010| > |---------------------------------------------------------------------| > |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| > |---------------------------------------------------------------------| > |RELENG_7 |n/a |n/a |n/a |last release + 2y| > |-----------+------------+--------+-----------------+-----------------| > |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | > |-----------+------------+--------+-----------------+-----------------| > |RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |June 30, 2010 | > |-----------+------------+--------+-----------------+-----------------| > |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | > |-----------+------------+--------+-----------------+-----------------| > |RELENG_8 |n/a |n/a |n/a |last release + 2y| > |-----------+------------+--------+-----------------+-----------------| > |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| > |-----------+------------+--------+-----------------+-----------------| > |RELENG_8_1 |8.1-RELEASE |Extended|not yet |release + 2 years| > +---------------------------------------------------------------------+ [snip]