Hi Internals,
Why not EOL until Zend has it's ZCE program up to date with the latest
version?
Kind regards,
Chris van Dam
Op 11-12-12 02:29 schreef Johannes Schlüter <johan...@php.net>:
>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
>
E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. The use of
it by others is prohibited. Trace is neither liable for the proper and complete
transmission of the information contained in this communication nor for any
delay in its receipt.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
