Ilia,
If you are referring to APC as the stable cache, that unfortunately is > not entirely correct, it is still relatively easy to crash APC unless > some work-arounds are applied. I was speaking to a several people at > the conference just yesterday and they were indicating frequent > crashes with APC, the work-arounds appear to have solved their issues, > but those are not exactly obvious. Even more evidence that the situation for 5.5 is not the same as for 5.4, as a stable cache does exist for 5.5, when it still doesn't for 5.4... But either way: > > The discussion now is if we delay 5.5 to spend the time pulling it in > core. > > But either way (in core or not), ZO+ is open and working on 5.5 alpha. > So we > > could skip the core import, and just ship it today as gold, and it would > be > > adoptable straight away (unlike how 5.4 was). > > Well the question around the delay, is what is the negative > consequence of the delay, versus the advantage of having a built-in > opcode cache shipped as part of 5.5 which is likely to give many > people an impetuous to upgrade from their current 5.2/5.3 install. > What advantage do we get by doing a surface level inclusion? We're not going to refactor the engine for 5.5. We're not going to do any deep integrations in 5.5 (or as the RFC puts it, "soft integrations"). So what is the advantage of inclusion? >From my eyes, the only advantage for a soft integration is the fact that the source code is bundled. It wouldn't be enabled by default (which is VERY ambiguous from the RFC). It wouldn't provide ANY benefit from it being in PECL with the exception that the source code ships together with core... What is the disadvantage to bringing it in 5.5? Well, there are a few: 1. We're holding up the 5.5 release indefinitely. Meaning that we're not time-boxed as the RFC process intends the release to be, but instead we're feature boxed. What happens if we approve this for 5.5, and in two weeks everyone working on it decides to go on vacation for two years. We're stuck in the same boat as we are with 6. We promised and agreed to do something, but for whatever reason didn't. That's EXACTLY what this time-boxed RFC process does. It prevents that from happening. 2. We've already delayed 5.5 by a month. When Zeev first offered to open source it, the message presented then was that it would be out in a few days (end of week I think was the original message), and it would only take a few days from there to integrate. Now we're a month later, and the source was just made available 1 week ago. Two weeks later than promised. And it's looking like an additional several months of work to integrate. I'm deeply concerned that "oh it should only take 2 months to fix up" could very easily turn into a LOT longer of a time... Which would be bad for everyone. 3. It's sending the wrong message. We have policies and procedures for a reason. Now, I have no issue with having a deviation policy that allows us to deviate, but let's be smart about the deviations. Doing a deviation here basically says the whole release process is bad, and we can do whatever we want whenever we want as long as it's popular. That's not why we agree on policies and procedures... My thoughts at least... Anthony
