The Case For Rapid Release Cycles

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 “rapid release cycle”. 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. “Rapid” depends on the context. Both Chrome and Firefox have adopted a six-week release cycle. As I mentioned before, six months could be considered “rapid” 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 “Long Term Support” (LTS) releases. Provide bug fix updates and security patches to these releases for three to five years. This provides a “safe” 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.

“Rapid releases of major versions are just for psychological effect and has no affect on the delivery pace of new features.” 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 “normal” 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.

“Rapid release cycles are for consumer software where you don’t have to care for backward compatibility.” 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, “There are no answers inside the building.”

“It forces people to upgrade too often and rewrite their code, or get left behind.” 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.

“Having lots of end-of-life (EOL) versions being used could be a security risk.” 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 of a framework, the developer) to be aware of a release’s EOL date. Using EOLed software is always a security risk.

While not specifically a concern with rapid release cycles, there’s a general mentality that major releases are “our chance to get it right.” Hopefully you’re a better software developer than you were even six months ago. Chances are you know more than you did then, and would approach solving problems differently now. Think six months before that, and six months before that. Now project this into the future. Where will you be in six months? Will you know more than you do now? Will you approach solving problems differently than you do now? If you’re a good software developer, you will never get it “right”—you will always be better six months from now than you are today and know more than you know today. 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.

3 Comments

  1. Artur Bodera
    Posted August 8, 2011 at 5:03 pm | Permalink

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

    Well said. Totally agree. It’s a good strategy for a smaller project. Might work for a mid-size project with an “agile angle” and a well managed team. Will mostly be a disaster for a large project.

    Now from a different angle – frameworks are NOT applications, applications are NOT frameworks. Each new application I build is leaps and bound, lightyears ahead of previous one, as I always use all the newest tools, resources, knowledge and a sum of my experience (which makes me who I am).

    From a maintenance perspective, when I have to fix, extend or just “adjust” older applications (which today seem like I carved them in stone with my teeth) I most certainly appreciate components (frameworks, libraries, tools) that have been updated and bug-fixed along the way, so I can just swap ver 1.01 with ver 1.31 and go to sleep being a happy camper.

    Furthermore, I love it when I upgrade my PHP 5.0 to PHP 5.3, or MySQL 5.00 to 5.5, or newest jquery, just to find that my application not only is more secure, but also noticably faster, because there are some inside-changes that I don’t care how they work, but I love the result.

    Emphasis put on the word “upgrade”.

    Major vs minor is like evolution vs revolution. Most projects/apps that I’ve been part or has built, have had agile processes. This means that we innovate, iterate, learn and build huge things from sum of smaller parts. In start-up world that is a general expectation for most projects — 12mo for first GA beta is not enough any more. A workable prototype is expected in a month or two, otherwise it might be obsolete (or already done by someone else). But when it launches and stabilizes, more innovation comes in and “frozen”, working parts are expected to be stable and secure.

    Framework is like a pillow, helpful when someone wants to kick you in the butt. Frameworks are not to innovate, but to give you a solid, dependable foundation you can build on. Putting any framework in an accelerated, bc-breaking life cycle will defeat that purpose.

  2. Posted August 9, 2011 at 7:29 am | Permalink

    Hi Artur,

    It’s important not to let talk of rapid releases detract from why this proposal exists. A framework has one very focused objective. It’s a stable platform over a period of time on which to build stuff. To assist in that objective we will very likely designate certain releases as LTS which can exist for many years benefiting from any security or high priority fixes necessary. Not only will this not result in the planet imploding, it will also ensure LTS versions are more stable than what ZF currently proves to be. Bug fixes of a non-essential nature, by their omission, will prevent any unintentional introduction of backwards incompatible changes and other inconsistencies where user workarounds and reliance on certain bugs are broken by such fixes. Fixing a bug, by its nature, is a changing of behaviour. LTS releases should prove exceptionally stable over time.

    In return for having an LTS version with a greater degree of stability, non-LTS versions will follow an accelerated development process when it makes sense to do so. Obviously, we won’t start new major versions without a good reason to do so but we want to get ahead of the PHP version adoption curve where possible so that, when many PHP developers get around to adopting new versions, a solid Zend Framework version is already there waiting for them. This is a radical departure from how frameworks are currently developed at the tail end of PHP versions.

    The accelerated model, once you recognise that LTS releases will occur, has a lot of merit. We can more rapidly integrate new thinking and learning, more rapidly respond to what PHP developers want and need and, critically, reduce the migration curve from version to version. We need to start favouring iterative improvements over complete rewrites. If following the curve does not appeal to all developers (and why should it?), the LTS releases will always be there a couple of steps behind offering the rock solid alternative, and where you want to mix LTS and edge components, well, the whole lot is versioned by component and packaged so you can mix up your preferred batch of goodies ;).

    Paddy

  3. Posted August 12, 2011 at 7:26 am | Permalink

    Totally agree. Well said.

    Great post.

2 Trackbacks

  1. […] Holt has posted an interesting article on why rapid release cycles are a good idea for Zend Framework major versions. For a framework (and maybe for other software), I think the […]

  2. […] 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 […]