On Tue, 2012-12-11 at 08:55 +0900, Yasuo Ohgaki wrote:
> 2012/12/10 Adam Harvey <ahar...@php.net>:
> > On 10 December 2012 18:58, Johannes Schlüter <johan...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
