ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

On predictable PHP release cycles

There is currently a vote going on to include Zends Optimizer+ opcode cache into PHP core. I am very happy with finally adding an opcode cache to the core distribution if only because it then forces to actually ensure that there is a working opcode cache together with every new release. What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages. First and foremost it will ensure that developers that propose a new feature will have a better idea of when their feature will be part of a release. This can encourage developers to actually bother with sharing code and it also prevents developers from getting disgruntled if their feature is deemed not yet ready for the upcoming release or even more importantly prevents half baked solutions from being pushed in just to prevent an unknown further wait time. Furthermore it makes it easier for PHP end users, especially larger frameworks and application maintainers, to plan their releases. Finally it poses the chance that distributions will better schedule the freeze time for PHP versions, rather than the current rather random choice they tend to do.

Now people (ok Zeev in particular) are throwing around numbers in regards to adoption rates. They are talking about how quickly new features are adopted by frameworks etc. However none of the presented data holds much use for this argument. We have never had predictable releases over a long period of time. So right now we are still not predictable. Furthermore it takes time for these frameworks/applications/distributions, even if they have the trust that PHP actually follows its release cycles, to actually start getting used to this and leveraging this in their planning.

The reality is that its quite easy to find a new must have feature for every release that makes it worth in the short term to delay the release a little bit, thereby getting a feature a feature 10-11 months earlier. But if we do this even every 2nd or 3rd release, we loose the benefit of a predictable release cycle. What is even stranger for this case is that we are just talking about an extension here. Its not a language feature, there is no engine level integration. So even if its not added to core, people can easily get Optimizer+ via PECL. So in this case we are not talking about people having to wait another 10-11 months. Don't get me wrong I think getting an opcode cache into core is awesome, but the reality is that shared host users will probably still not have access to it (correct me if Optmizer+ is more shared host friendly than APC) and the rest can still get it, albeit with a bit more effort. So I really do not understand the rush here ..

Update: Anthony makes some additional very good arguments why there is no reason to delay.

Comments



Re: On predictable PHP release cycles

I'd argue that having an opcode cache that we know is ready for 5.5, and, more importantly, for every release going forward, is likely more important than adhering to the schedule this time. I've heard from many people -- from hobbyists to large companies -- that problems with APC in 5.4 have been a barrier to them adopting 5.4. If we want to ensure that new versions are adopted quickly, this is an important piece of infrastructure for the language to have in place.

Re: On predictable PHP release cycles

So if ZO+ is ready 2 months after PHP 5.5 is out via PECL, then users will already have distros etc providing 5.5 earlier which is a plus and people would have PHP 5.5 with ZO+ equally fast as when it would be bundled. As the alternative is to have ZO+ bundled with 5.6 there is zero advantage to delaying 5.5 really.

Re: On predictable PHP release cycles

APC is the exact reason I haven't upgraded to 5.4. Very harmful to the community to say APC will be packaged by default and almost a year later no stable update.

From here on out; I won't rely on APC and will be looking at alternatives such as XCache since they are sadly, less volatile.

Re: On predictable PHP release cycles

@Justin I don't recall anything more than normal discussion about the pros and cons of including APC with PHP 5.4. In the early days of discussion about PHP 6 there was a plan to include APC with PHP 6, but that decision was made long ago and PHP 6 work was shelved for various reasons (mostly related to lack of volunteers).

@Lukas, I get the impression that the wider PHP community is now expecting PHP 5.5 to include "opcache" [the current front runner for its new name].

For the record, I voted to integrate opcache into PHP 5.5.

Re: On predictable PHP release cycles

well the RFC does an insufficient effort at explaining the draw backs of rushing it in. but it's good to hear that community expectations affect core behavior these days ;-)

Re: On predictable PHP release cycles

Predictable release cycles are a must.

This way distributions, which also use time-based release cycles, can better align with php releases.
Which means there should in the end be less old versions out in the wild.
Which in turn benefits framework devs, etc...

Back on topic: as soon as you can install the O+ via pecl, 3rd-party rpm repo, and as dll, the situation will not be worse in any way that it is now. And, if APC history is to teach us something, better give the optimizer code as much exposure as we can before we declare it stable.

So no need to delay release imho.

Re: On predictable PHP release cycles

So it seems like the RFC is being declared as accepted by Zeev, although there are still debates if it requires a 2/3 vote or not. Obviously its much harder to achieve a 2/3 result when you have 3 options. It feels a bit like splitting hairs. Then again its a bit bizarre that a vote result requiring a 2/3 majority (ie. the release process) can be indirectly overturned via a vote that only seems to require a 1/2 vote result, especially when the main effect of this vote could be reached without overturning the 2/3 majority that previously voted, by simply waiting until 5.6 to include ZO+.

At any rate, imho its time to move on, however bad the decision might seem, we will never get perfect wording in any of this, even if we hired lawyers to work on this. So we have to keep some common sense here. Clearly people want ZO+ in core by a landslide and a very clear majority of these people is willing to ignore the previously passed release process. So it goes.