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

He points out some things that come along with having predicability around the software releases like developers knowing when/if their changes will make it into the next release. It also makes it easier for end users to plan their releases of their own software, knowing when they'll be getting a feature. In this particular case, though, he doesn't quite understand the delay as the Zend Optimizer+ isn't a change to core, it's an addition:

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 [...] and the rest can still get it, albeit with a bit more effort.

There has been some discussion recently on the Zend Framework mailing list around release cycles. I proposed a release cycle of six months for major versions (someone else suggested eighteen months, which may be more reasonable for a framework). Rapid releases allow one to accelerate the cycle of building, measuring, and learning. Gathering data from actual usage (measuring) provides an opportunity for learning that can be applied to the next release (building).

He points out that the post isn't specifically targeted at the Zend Framework project, merely that it was the inspiration point for the idea. He talks about what rapid release cycles are and what it can give the team that implements it - less worries about backwards compatibility breaks, a potential encouragement for development pacing and the ease for the customers doing upgrades.

A rapid release cycle allows you to apply new learning, knowledge, and perspective as often as possible. Do your best today, and give yourself opportunities to do your best in the future as well.

I'm no continuous deployment expert, but it's gotten some attention after yesterday's highlight at an Etsy board meeting. Companies making the most of continuous deployment were designed to do so from the very early stages. [...] It takes a lot of discipline to implement all of the [testing methods and development cycles]. It takes even more to make sure that these kinds of processes get put in place early in a company's life.

The parts of a successful continuous deployment process include unit testing, a controlled feature cycle, black box testing and good instrumentation to keep track of it all. Clay wonders why, when there's so many tools and information out there about CD, companies still wouldn't implement it. He notes that putting it in after the fact is very rare and is usually avoided by the "if it ain't broke, don't fix it" mentality.

It took us a while to get here, but Midgard is finally entering a release cycle which will drop support for PHP4. The reasons are quite clear: simplicity and speed. The whole PHP4 end of life business has caused quite a bit of discussion in the PHP community.

The group chose to go PHP5 only for speed reasons (like advancements in their Query_Builder component) and the new features that PHP5 will allow in their MidCOM component.

Over the last few years, I've made it a point of trying to respond to at least some of the "PHP is dead"-type articles that crop up on the Net from time to time. The latest one comes from Hiveminds and reveals a complete misunderstanding of almost every point it covers.

He notes that though the article seems to be a coherent whole for why PHP is dwindling, it's "based on nothing more than a string of misinformed concepts cobbled together to give the appearance that the author knows what he or she is talking about". Marco comes back against each of the points made in the article, setting things right and eliminating some of the FUD (fear, uncertainly, and doubt) that the Hiveminds article spreads.