Release Cycles and Lifecycles of software (and hardware) are interesting. How these releases are structured, who does them, and the planning and development process is fascinating from a rollout-of-features perspective. Development release cycles can also be applied to services.
Operating System Release Cycles
Of course we know how Microsoft is getting into trouble with their multi-year release cycle. Apple seems to beat them quite handily with a yearly release, but that is about hardware more than anything. My current comment on Apple’s OS is that it is pretty much like Microsoft, in that we get shitty releases, some patches, and then a better version (or not) in a year. Everything post-Lion has been a huge disappointment, little gadgety enhancements notwithstanding. The fact that the designer guy has had a complete run over Safari, not to mention Safari’s lagging technical chops should indicate how the helm of the software shop is undermanned, to say the least.
In any case, the 6-month release cycle of Fedora and Ubuntu is a pretty good timeframe (for an operating system). Of course Fedora server and Ubuntu LTS versions have a longer and different lifecycle due to stability and security issues.
Application Release Cycle
The 4 month WordPress release cycle is good for fairly complex applications (server or desktop/mobile). It should be obvious that bug fixes and point releases should be liberally sprinkled in to keep everyone aware of the relevance of an application (or operating system). They key of course is to provide value (not introduce new bugs), definitely squash current bugs, and of course security updates.
Unfortunately most organizations don’t do this well. Two recent examples spring to mind. CyberDuck’s MountainDuck which was a poor attempt at copying Transmit’s Disk functionality — and broke the base CyberDuck application functionality every other release or so. As well, the OSX implementation of CloudMagic, which also went on a yo-yo of implemented and broken functionality. (CloudMagic is a silly name, and ultimately a failed approach which is to remove information and the advantage of a large screen, essentially upsizing (slightly) the iOS app.)
Release Cycles and Professional Services
Release Cycles can be implemented in ongoing professional services. The key is to provide visible value (even if only conceptual) rather than a monthly task list and invoice. Here is a sketch of how one might approach this, with new and current clients.
- Begin with a version 0.1 which is a baseline, where we are
- If one has already been at work for 4 months or so, stretch back that amount of time. (April, August, and December are good months to have releases in.)
- Next major release is in the next month. Note that a major release doesn’t have to have major changes, just a numbering to put a stake in the ground and indicate a milestone for measurement.
- Now that there is a release cycle, one can put some structure around that (known process)
- Finally, add items to the development roadmap which consists of the major releases (and their point releases).
- Of course weekly meetings, email, chat, and wiki work should always take precedence, but now there is a set of time horizons around which to structure discussions.
Originally published at mcneill.io/release-cycles/