PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

The Case For Rapid Release Cycles

Note: This article was originally published at Planet PHP on 9 August 2011.
Planet PHP

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).

Zend Framework 2.0 should be released soon, and it has been four years since the last major release (1.0). This is not to imply that Zend Framework has been stagnant-far from it. There has been a ton of development effort and many improvements to Zend Framework since 1.0. I have a great amount of trust in the team, and I have complete confidence that Zend Framework 2.0 will be an awesome framework. This post is intended to make the case for rapid release cycles for software in general, and is not meant to be a criticism of Zend Framework or the development processes behind it. However, the discussions around Zend Framework's release cycle are what's prompting me to make this post.

First, let me describe what I mean by a aorapid release cyclea. In this context, I mean rapid releases of major versions. Put simply, major versions are those that allow backwards compatible breaks. This is somewhat controversial. I don't think anyone really has any big concerns with the rapid release of minor (introduction of new features while maintaining backwards compatibility) or maintenance (bug and/or security fix) releases. aoRapida depends on the context. Both Chrome and Firefox have adopted a six-week release cycle. As I mentioned before, six months could be considered aorapida for a framework.

For a framework (and maybe for other software), I think the following rules are necessary in order for a rapid release cycle to work:

  • Minimize backwards compatibility changes between major releases. Targeted and strategic refactoring, rather than major overhauls, are preferable if you are releasing often. Small backwards compatibility changes makes migrating from one major version to another much easier.
  • Mark some major releases as aoLong Term Supporta (LTS) releases. Provide bug fix updates and security patches to these releases for three to five years. This provides a aosafea option to those who value stability and don't want to upgrade very often. In the context of Zend Framework, it is obviously Zend's decision if they want to take on this burden. If not, then I don't think a rapid release cycle is viable.

What are the concerns with a rapid release cycle? I'll paraphrase, and then address, the major concerns that I've heard.

aoRapid releases of major versions are just for psychological effect and has no affect on the delivery pace of new features.a This is both true and false. See my earlier post on iterative vs. incremental development. If development is incremental and driven entirely by a pre-determined roadmap then there is no tangible differences between a aonormala and a rapid release cycle. The development of many consumer software packages is perceived as incremental, in which case major version bumps are mostly psychological. However, if you take an iterative development approach and build-in outside learning from end-users into your process, then a rapid release cycle gives you the chance to change course based on outside feedback. Learning opportunities are introduced that you would have never had if your software wasn't actually used by real people in the real world.

aoRapid release cycles are for consumer software where you don't have to care for backward compatibility.a This is related to the previous concern. My response is that rapid release cycles are for any product where learning from real-world usage and outside input can be used to improve the product. To quote Steve Blank, aoThere are no answers inside the building.a

aoIt forces people to upgrade too often and rewrite their code, or get left behind.a See my earlier note about minimizing backwards compatibility changes in each major release. Additionally, it is much easier to automate upgrades if the backwards compatibility changes are small. There should be little code rewriting for applications built using the framework with each major version upgrade of the framework.

aoHaving lots of end-of-life (EOL) versions being used could be a security risk.a See my earlier note about providing LTS releases. Each major release should come with a pre-determined EOL date. It is the responsibility of the end-user (in the case o

Truncated by Planet PHP, read more at the original (another 1084 bytes)