Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62907
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain strojny.net from 46.4.40.248 cause and error)
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-ID: <DA37258C-B438-4575-99F0-53829FA9894E@strojny.net>
Date: Sat, 8 Sep 2012 18:57:27 +0200
To:
  "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
Subject: Easing major version upgrades
From: lars@strojny.net (Lars Strojny)

Hi everybody,

with the release of PHP 5.4 a similar pattern happened as with the =
release 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 reasons for it:=20

1.) Incompatible and hard to change codebases that won=92t run on newer =
PHP versions
2.) Distributions slowly providing packages for new major versions
3.) Upgrades are hard, let=92s go shopping aka never change a running =
system
4.) Popular and/or simply required extensions like memcache, apc, etc. =
aren=92t prime-time ready for the new version

While point one to three are merely a point we can campaign for (or =
against), point four is something we can do better. Two anecdotes about =
the current state of PHP 5.4 and popular extensions: we don=92t have a =
(released) PHP 5.4 compatible version of the memcache extension and APC =
is still not ready for all of our users (including myself) but it is =
practically required for production setups. So we are six month into 5.4 =
but the perceived 5.4.0 is still due for a number of people. And this is =
something we should do better.

There are various ways how to handle that situation: the "broaden the =
core" initiative is one of them (and bundling a stripped down version of =
APC is surely a good idea) but I would like to propose a simpler =
solution: we find out by a yet to be exactly determined combination of =
community survey and data analysis which PECL extensions are the most =
popular ones and make sure 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. If the most popular extensions aren=92t =
compatible, the version 0 of a major release cannot ship.

I'm not suggesting this will make everything nice and shiny but it will =
certainly ease the pain for our users.

cu,
Lars=