Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <DA37258C-B438-4575-99F0-53829FA9894E@strojny.net>
References: <DA37258C-B438-4575-99F0-53829FA9894E@strojny.net>
Date: Sat, 8 Sep 2012 20:23:43 +0200
Message-ID: <CAEZPtU43bf93wn69oF01Hr93_Pn=fmQo1VyMLb29N+ZjgZ9wZA@mail.gmail.com>
To: Lars Strojny <lars@strojny.net>
Cc: "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Easing major version upgrades
From: pierre.php@gmail.com (Pierre Joye)

hi Lars,

On Sat, Sep 8, 2012 at 6:57 PM, Lars Strojny <lars@strojny.net> wrote:

> with the release of PHP 5.4 a similar pattern happened as with the releas=
e of 5.3: while we want people to upgrade as fast as possible, it is often =
a bumpy road for users to migrate to new versions. There are various reason=
s for it:
>
> 1.) Incompatible and hard to change codebases that won=92t run on newer P=
HP versions

BC breaks between x.y+1 are not allowed anymore. So that should not be
a problem, or much more smaller issue than ever before.

> 2.) Distributions slowly providing packages for new major versions

debian, which was known to be slow at updating, will have 5.4 in next
(or already has). RHEL or other centos with long term frozen versions
are hopeless for what I can say.

> 3.) Upgrades are hard, let=92s go shopping aka never change a running sys=
tem

What do you mean here?

> 4.) Popular and/or simply required extensions like memcache, apc, etc. ar=
en=92t prime-time ready for the new version

Right, that's acutally the main problem for many users I met (incl.
too day at the DevCon in Hamburg). There is not much we can do without
much more early feedbacks (during the whole RCs phase), and not after
the final release.

> There are various ways how to handle that situation: the "broaden the cor=
e" initiative is one of them (and bundling a stripped down version of APC i=
s surely a good idea) but I would like to propose a simpler solution: we fi=
nd out by a yet to be exactly determined combination of community survey an=
d data analysis which PECL extensions are the most popular ones and make su=
re that the top X of them is ready when release 0 of a new major version is=
 released. And we define this as a required part of our  release process. I=
f the most popular extensions aren=92t compatible, the version 0 of a major=
 release cannot ship.

No chance to achieve that with the current resources. Simply impossible.

The campaign I am doing since a year is to explain our users (drupal
devs, symfony, at all confs I go) how easy it is now to contribute to
PHP, to test RCs as well as all the extensions they use with PHP.

About APC, yes, I definitively would like to get an opcode cache only
version of APC, with very few or almost no ini setting, no user cache,
cleaned from all these esoteric ( 0.01% of the users using them), etc.
But that's a different topic :)

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org