Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58483 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61187 invoked from network); 2 Mar 2012 13:43:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Mar 2012 13:43:32 -0000 Authentication-Results: pb1.pair.com header.from=adam@adamharvey.name; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=adam@adamharvey.name; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: adam@adamharvey.name X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:33266] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/00-11220-38EC05F4 for ; Fri, 02 Mar 2012 08:43:31 -0500 Received: by iaeh11 with SMTP id h11so2581950iae.29 for ; Fri, 02 Mar 2012 05:43:29 -0800 (PST) Received-SPF: pass (google.com: domain of adam@adamharvey.name designates 10.42.154.195 as permitted sender) client-ip=10.42.154.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adam@adamharvey.name designates 10.42.154.195 as permitted sender) smtp.mail=adam@adamharvey.name; dkim=pass header.i=adam@adamharvey.name Received: from mr.google.com ([10.42.154.195]) by 10.42.154.195 with SMTP id r3mr6817953icw.36.1330695809341 (num_hops = 1); Fri, 02 Mar 2012 05:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamharvey.name; s=google; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=GIZ5i00OhlJ6o1hkSkJWTXsZz73CIWqYW6YR/jzkLoU=; b=pZ1+YDRRv0B0jRV/WGPdXU+lwjiMJukJKgQQqQPmCx4PZJqVZb3UQw1GD7SoL53cxL Pio3h0Ig28qmEoc6cWgFB+iyyFNt5tJdyTJudrqhsQant2+v/6fUHSXjRVhA4MpsQE0/ sIckRwmTW4uNyWXZZvErFo6rajrrvI+yjvjh4= Received: by 10.42.154.195 with SMTP id r3mr5589317icw.36.1330695809275; Fri, 02 Mar 2012 05:43:29 -0800 (PST) MIME-Version: 1.0 Sender: adam@adamharvey.name Received: by 10.42.108.137 with HTTP; Fri, 2 Mar 2012 05:43:08 -0800 (PST) In-Reply-To: References: Date: Fri, 2 Mar 2012 21:43:08 +0800 X-Google-Sender-Auth: TNb2aH7CEB8q0MR3o5QeI7HQIbY Message-ID: To: Simon Schick Cc: Gustavo Lopes , Pierre Joye , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQle0x7wwhEIwHQ4yjggdVdRrsZqU5f2nZEAN6saUCc8MgaXn3HN2Aj+zse/LO3CKlcQjTki Subject: Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL From: aharvey@php.net (Adam Harvey) On 2 March 2012 21:34, Simon Schick wrote: > One or two years is way to short if you'd ask me. A major release should = be > supported with all kind of bug fixes for min. 3 years after a new release > has been brought out. Specially if it's a wide-spread language like PHP t= hat > has been implemented by such big and lazy companies. Please do not > misunderstand that. Lazy is not meant in the way that they are doing > nothing, but that it takes way more time as it does for me installing a n= ew > PHP version on my 2-3 servers. There has to be a limit at some point because the maintenance burden becomes too difficult. With the two year proposals, we're going to end up in a position next year where we'll have active 5.3, 5.4, 5.5, 5.6 and trunk trees (or whatever 5.5 and 5.6 get numbered). That's at least one too many, frankly, but there was always going to be some awkwardness during the transition to the new release process and I for one would prefer to err on the side of caution. Honestly, I'd probably prefer 9 months of bug fixes (up to the release of 5.5 in November/December) + 9 months of security fixes, but I don't want to muddy Pierre's RFC further, and I'd like to hear the opinions of the RMs, since this is very much on them. The point of the release process RFC was to clarify this =E2=80=94=C2=A0rel= eases from 5.4 onwards have a clearly defined two year bug fix + one year security fix lifetime. I think that's reasonable, and it falls into line pretty well with a number of other languages. The fact that we're in this position is a one-off, and I don't think we can prolong it indefinitely (nor do we really have the resources to). Adam