Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Easing major version upgrades

Posted by Lars Strojny 
Lars Strojny
[PHP-DEV] Easing major version upgrades
September 08, 2012 07:00PM
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:

1.) Incompatible and hard to change codebases that won’t run on newer PHP versions
2.) Distributions slowly providing packages for new major versions
3.) Upgrades are hard, let’s go shopping aka never change a running system
4.) Popular and/or simply required extensions like memcache, apc, etc. aren’t 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’t 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’t 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye
Re: [PHP-DEV] Easing major version upgrades
September 08, 2012 08:30PM
hi Lars,

On Sat, Sep 8, 2012 at 6:57 PM, Lars Strojny <[email protected]> wrote:

> 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:
>
> 1.) Incompatible and hard to change codebases that won’t run on newer PHP 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’s go shopping aka never change a running system

What do you mean here?

> 4.) Popular and/or simply required extensions like memcache, apc, etc. aren’t 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 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’t 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,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lars Strojny
Re: [PHP-DEV] Easing major version upgrades
September 08, 2012 09:30PM
Hi Pierre,

Am 08.09.2012 um 20:23 schrieb Pierre Joye <[email protected]>:
[...]
>
>> 3.) Upgrades are hard, let’s go shopping aka never change a running system
>
> 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’s indeed a different topic but it would ease a lot of pain to have a fully compatible APC from day one.

cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Lerdorf
Re: [PHP-DEV] Easing major version upgrades
September 08, 2012 09:40PM
On 09/08/2012 12:26 PM, Lars Strojny wrote:

> That’s indeed a different topic but it would ease a lot of pain to have a fully compatible APC from day one.

The first step to that is to make sure all new language features include
the necessary changes to APC. And despite what Pierre thinks, it hasn't
been the non-opcode features that have been holding us back. It has been
traits and the interned string changes in the engine for the most part.

We could drop some of the ini switches and just hardcode some things,
but there are really just two main things in APC. The opcode cache and
the user cache. The user cache is used quite a bit out there, but I
suppose we could still have a pecl/apc that adds that back.

But it all comes down to someone actually doing the work. We don't have
a lot of people capable of doing this. I would say getting opcode
caching right is even more complicated than the engine code itself. In
the engine we don't have to worry about concurrent access to the same
chunk of memory - essentially threaded programming and it gets really
nasty. Gopal even patched Valgrind to help debug and catch APC issues.

-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login