Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64244
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 217.114.211.66 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Adam Harvey <aharvey@php.net>, PHP internals list
 <internals@lists.php.net>
In-Reply-To: <CAGa2bXYMumfUM6y3zkzqhtVnhdYzR7AYzZ_PZO1UNTGuTk_Ctw@mail.gmail.com>
References: <1355137083.3178.24.camel@guybrush>
	 <CADajX4CMd4S4nRqpFdB6hR=bPRaEGHQkDSH4uGrPA9gxP24y0g@mail.gmail.com>
	 <CAGa2bXYMumfUM6y3zkzqhtVnhdYzR7AYzZ_PZO1UNTGuTk_Ctw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Organization: PHP Development Team
Date: Tue, 11 Dec 2012 02:29:00 +0100
Message-ID: <1355189340.3178.106.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP 5.3 - end of live schedule
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Tue, 2012-12-11 at 08:55 +0900, Yasuo Ohgaki wrote:
> 2012/12/10 Adam Harvey <aharvey@php.net>:
> > On 10 December 2012 18:58, Johannes Schlüter <johannes@php.net> wrote:
> >> As of this date the 5.3 branch will go to extended support and should
> >> receive security fixes only. Releases will be made based on need.
> >>
> >> Please mind that the above schedule is tentative and unpredictable
> >> events might change this.
> >>
> >> Comments?
> 
> I think there is no consensus of EOL of 5.3 from last discussion
> as Pierre mentioned.

In the thread "[RFC] discussions, about a 5.3 EOL" mostly supported
option #1 from the RFC, some were convinced and changed their opinion
for #1, one wished for some LTS kind of model (which is an independent
thing which means replacing the current release model, aka nowadays
relevant for 5.5) Some people commented about waiting for 5.5 but not as
much. Also the proposer of that RFC mentioned this had to be decided
"now" depending on 5.4's release, but apparently didn't see need to
formalize this by a vote which I also interpreted(!) as part of a
consensus.

> > At the very least, I think we should keep full support going until
> > 5.5.0 final is out, which it strikes me probably won't be in February
> > at our current rate.
> 
> Anyway, I'm +1 for extending 5.3 EOL at least until 5.5.0 release.

Well, people don't trust .0 versions, so we then should wait for 5.5.1
or 5.5.2 ... but by then 5.6 will already be in development, so why not
wait for 5.6?

But more seriously: 5.3 won't stop working and will still receive
critical fixes for at least a year. Users will also face less risk while
updating that a fix broke something by accident.

As a recent example take a look at commit 6dff07 ("Fixed bug #63512
parse_ini_file() with INI_SCANNER_RAW removes quotes from value"). This
change slightly changes the behavior. People might treat the current
behavior, which was "introduced" while fixing #51094 for 5.3.15 as
feature even though (I assume) most users would see #51094 and #63512,
as clear bugs. Such changes force people to verify each and every
release. If we limit ourselves to critical issues we a) reduce the risk
of adding new bugs (like #63512) b) make the verification process for
users simpler as less things in the code change. While, yes, there might
be a few more bugs, but they are at least documented in the bug tracker
and fixes and different work-arounds exist. (and if too many people
stumble over it, it can still be escalated and become "critical")


        A bit related rant: Looking at the commit times of some merges
        it seems unlikely that all changes are actually tested in all
        branches. When there is less than two minutes between a commit
        to 5.3 and merge to 5.4, 5.5 and master I assume that often the
        only test is about merge conflicts -- not even a compile test.
        Of course people might do some manual things outside git, do
        merges with --no-commit first and later commit or do some
        rewrite in between ... but I assume the less branches we have
        the higher the percentage of tested branches is
        (pessimistically: from 25% to 33.3%)

> How about announce 5.3 EOL in 5.5 RC release notes?

RCs don't reach the same audience. PHP 5.3.x release notes need it.
5.5.0-final release notes will certainly receive our boilerplate "All
users are suggested to update" snippet, maybe a bit extended.

Which is also why I hope we reach an agreement before release 5.3.20 on
Thursday next week.

johannes