Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62911
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
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
In-Reply-To: <CAEZPtU43bf93wn69oF01Hr93_Pn=fmQo1VyMLb29N+ZjgZ9wZA@mail.gmail.com>
Date: Sat, 8 Sep 2012 21:26:32 +0200
Cc:
  "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9CC0AAEC-C796-4654-A53A-5A2F3034E67E@strojny.net>
References: <DA37258C-B438-4575-99F0-53829FA9894E@strojny.net> <CAEZPtU43bf93wn69oF01Hr93_Pn=fmQo1VyMLb29N+ZjgZ9wZA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Subject: Re: [PHP-DEV] Easing major version upgrades
From: lars@strojny.net (Lars Strojny)

Hi Pierre,

Am 08.09.2012 um 20:23 schrieb Pierre Joye <pierre.php@gmail.com>:
[...]
>=20
>> 3.) Upgrades are hard, let=92s go shopping aka never change a running =
system
>=20
> What do you mean here?

A general reluctance to change production systems because "they work". =
But as I said, not our problem.

[...]

> No chance to achieve that with the current resources. Simply =
impossible.

That depends on what duties the internals developer define for =
themselves. If it is to run test suites of the top X extensions and =
document the outcome it totally sounds possible. It could even be part =
of a continuous integration process. For me it is not so much about more =
work, but about more transparency (e.g. the memcache extension and 5.4, =
only thing missing was a PECL release). Again, the proposal, a little =
more concise:

  - Find out about top X extensions
  - Define their compatibility as blocking for a new release (as an =
adjustment to the release process)
  - Maintain a status page and the related bugs
  - Publish the current compatibility status so that people know

The alternative to not fixing this problem is an increasing gap between =
what we think people should use in production and what they actually use =
and expect us to maintain. Additionally fixing compatibility issues is =
usually a good starting point for new talent.

[...]

> 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 :)

That=92s indeed a different topic but it would ease a lot of pain to =
have a fully compatible APC from day one.

cu,
Lars=