Back in April, I blogged about how we were adopting a release train model for our Open Source projects. Since then, we've rolled out the same process to our commercial products Clearspace and Jive Forums. The release train is a fairly fundamental departure from how we've done releases in the past, so we wanted to provide more details about exactly how it works.

 

Why did we make a switch in how we build our software? There were many motivating factors, but the general theme is "move as fast as possible with high quality". For end users of our products, the key thing to know is that there will be a new release every three weeks. Each version contains bug fixes and new features and we're committed to maintaining high quality for every release (no more rushed bug fixes a week after a release). The graphic below illustrates how this process works:

 

 

Each release (from top to bottom of the graphic) takes a total of nine weeks: three weeks of planning, three weeks of development, and three weeks of QA. All three processes run in parallel, which leads to the three week release cycle.

 

Answers to common questions:

 

Q: Do we expect customers to upgrade every three weeks?

A: No, that's unreasonable in most environments. We've made it as easy to do upgrades as possible, and we hope you'll upgrade at least once per quarter to take advantage of all the great changes. When you do upgrade, the release train process will help ensure you're on high quality code.

 

Q: How will version numbers work?

A: Each release will get a minor version number: 1.5, 1.6., 1.7, etc. Major version numbers will change approximately once per year.

 

Q: How will you develop major new features that take more than three weeks?

A: Good question. No model is perfect and we're already working on new features that will take more than one train cycle to fully finish. In those cases, we're breaking the projects into milestones and using code branches as necessary.

 

Other Release Train Fun

 

The release  train has had a deeper cultural impact than just being a way that we engineer our software. The marketing team now times a lot of their work on the train, and even our major happy hours are now on the three week cycle. Late afternoon of every third Friday, we gather the company for a demo of the new features and then adjourn for partying.

 

Time will tell how well this new process works, but we're excited about it and the results so far are promising.