PHP 5.3 - end of live schedule View as Markdown

Hi,

I'm not suggesting we necessarily extend full support, but I wonder if
one year of critical bug fixes and security updates will be enough.

In my opinion key for this is PR. Get people to migrate to 5.4. We are
still flexible to interpret what "critical" issues are, and to merge and
release those. (And extend that time if we see too little migration)

I couldn't agree more.

For distributions at least Ondřej supported this option from Debian
perspective. In my opinion distributions in fact would be happy with
this. all they want are "critical" fixes in their "stable" and backport
only this. The more we prefilter the simpler for them.

To be honest, Debian isn't really the distribution I'm worried about.
Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles
off, it seems.

RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is
supposed to be out in the second half of next year, but history (and
my own experience both in supporting users and dealing with vendors)
suggests that RHEL users are slow to upgrade. Ubuntu won't have
another LTS release until 2014.

Please also mind: Most bugs exist for years, most are older than 5.3. If
they lived with those on 5.2 they are no stoppers to migrate away from
there. The biggest category of 5.3-only bugs is around gc. PHP 5.3 won't
stop working and for operations there is no big difference after
February 2013 ... rather less risk of getting bug fixes which, by
accident, change behavior. Therefore after February 2013 users updating
need less validation when updating.

All true as well. And as I said, I'm not really gunning for full
support to be extended (beyond 5.5.0 final, anyway).

I think the idea of being flexible on this is fine so long as there's
an eventual hard and fast date announced some time next year. Let's
see how the distro situation shakes out, and how the charm offensive
in the first half of next year goes in terms of getting users to
upgrade to 5.4 and 5.5. :) I just wanted to flag it, mostly.

Adam

2012/12/10 Adam Harvey aharvey@php.net:

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

Hi,

There was no consensus, I am not sure where you get the idea.

By spending the time to go through the thread, taking the opinions
stated there, filtering out side discussions (like LTS based release
models etc) evaluating it (partly subjective) and summarizing it as in
the mail starting this thread.

However, we discussed to wait a bit before proposing the RFC to
clearly and cleanly define the EOL of 5.3.

Your message saying "5.4 was released on March, 1st. That's why I asked
this question now while it should have been done before." which is one
of the last from the thread doesnt' sound like delaying for additional
3/4 years for a decision.

I will clean up this RFC and call for vote later this week (most
likely tomorrow). It is very important to follow this step instead of
simply say, hey, I will go down this way because I like it ;-)

feel free to do what you want.

The delay is way too short for 3rd parties to adapt.

If people can provide reasons to extend it I'm open to hear those.

johannes

As a data point, Drupal 8 is slated to target PHP 5.3. Probably 5.3.10
and up, with release targeted in the second half of 2013. That is based
primarily on our investigation into what is actually shipping in Linux
distributions, and what the market looks like it will probably look like.

There's still plenty of places deploying Drupal on PHP 5.2, even though
I try to avoid using them myself, including large "enterprise" hosting
services.

(I'd love to be pushing to PHP 5.4 faster, but the lag time for
distributions and hosts is painful.)

--Larry Garfield