On the Laravel News site there's an announcement posted about a change in the Laravel release schedule, an update from the original 2013 announcement.

Yesterday, Taylor announced on Twitter that this is going to be changing to a January and July cycle, pushing each release out a month from its current schedule.

This has two primary advantages for the development team and the first is it allows more time for testing after Symfony’s release. The second advantage is it’ll better coincide with Laracon, the yearly Laravel conference.

This means a bit of a delay on the release of the next major version of the framework (v5.4) but only by one month. The six month cycle will then resume after that slight delay. You can find out more about the remainder of the release cycle in the original post based on Taylor's comments at Laracon 2013.

Lukas Smith has a new post today about what he sees as an important part of PHP (or really most open source projects) - a predictable release cycle. It centers around the recent proposal to introduce the Zend Optimizer+ into the core and how it seems to be causing a delay with 5.5 (maybe up to 2 months).

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.

Bradley Holt has a new post to his blog today talking about something he's a fan of in his development processes - rapid release cycles - and how something like the Zend Framework could benefit from it.

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.

In a recent post to his blog Clay Loveless looks at something he believes is important to create quality software in any organization - continuous deployment (CD).

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.

According to Henri Bergius, the next version of the Midgard software will be PHP5 only:

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.

According to Henri Bergius, the next version of the Midgard software will be PHP5 only:

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.

In response to this recent article from the Hiveminds website, Marco Tabini has a few choice words about some of the topics they cover in the article, and cover incorrectly.

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.

In response to this recent article from the Hiveminds website, Marco Tabini has a few choice words about some of the topics they cover in the article, and cover incorrectly.

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.