Time-based releases are good for community
There was a bit of discussion lately on feature-based vs. time-based release schedules in OpenStack, and here are my thoughts on it. In a feature-based release cycle, you release when a given set of features is implemented, while in a time-based release cycle, you release at a predetermined date, with whatever is ready at the time.
Release early, release often
One the basic principles in open source (and agile) is to release early and release often. This allows fast iterations, which avoid the classic drawbacks of waterfall development. If you push that logic to the extreme, you can release at every commit: that is what continuous deployment is about. Continuous deployment is great for web services, where there is only one deployment of the software and it runs the latest version.
OpenStack projects actually provide builds (and packages) for every commit made to development trunk, but we don’t call them releases. For software that has multiple deployers, having “releases” that combine a reasonable amount of new features and bugfixes is more appropriate. Hence the temptation of doing feature-based releases: release often, whenever the next significant feature is ready.
Frequent feature-based releases
The main argument of supporters of frequent feature-based releases is that time-based cycles are too long, so they delay the time it takes for a given feature to be available to the public. But time-based isn’t about “a long time”. It’s about “a predetermined amount of time”. You can make that “predetermined amount of time” as small as needed…
Supporters of feature-based releases say that time-based releases are good for distributions, since those have limited bearing on the release cycles of their individual subcomponents. I’d argue that time-based releases are always better, for anyone that wants to do open development in a community.
Time-based releases as a community enabler
If you work with a developer community rather than with a single-company development group, the project doesn’t have full control over its developers, but just limited influence. Doing feature-based releases is therefore risky, since you have no idea how long it will take to have a given feature implemented. It’s better to have frequent time-based releases (or milestones), that regularly delivers to a wider audience what happens to be implemented at a given, predetermined date.
If you work with an open source community rather than with a single-company product team, you want to help the different separate stakeholders to synchronize. Pre-announced release dates allow everyone (developers, testers, distributions, users, marketers, press…) to be on the same line, following the same cadence, responding to the same rhythm. It might be convenient for developers to release “whenever it makes sense”, but the wider community benefits from having predictable release dates.
It’s no wonder that most large open source development communities switched from feature-based releases to time-based releases: it’s about the only way to “release early, release often” with a large community. And since we want the OpenStack community to be as open and as large as possible, we should definitely continue to do time-based releases, and to announce the schedule as early as we can.
Leave a comment
Ubuntu Server blog
- An error has occurred; the feed is probably down. Try again later.
Seeing the fnords 
Time Based Release are the best in my perspective as you don’t want to overkill the fun of a new release plus with the release being time based there is a accumulation of features and new stuff and that’s best.
Given the current development infrastructure, what are the specific differences between how an individual commit is treated and a release? You mentioned that packages are already built automatically. Is the web documentation only pushed out on a release? Is there more work required to deploy a release?
The diablo milestone time based releases are very nice. What would be the downside to allowing Glance, Nova, or Swift 1.4.2.X feature update releases in between the milestones?
The key difference is that for milestones and releases, a few days before we cut a specific release branch out of trunk (the milestone-proposed branch) on which only bugfixes are accepted (see http://wiki.openstack.org/BranchModel). Packages are built from that branch. there are also some games around versioning, but overall the process is exactly the same.
In “Release early, release often” you describe exactly what we do at Rackspace for Cloud Files. We have a web service that is one deployment and it runs the latest version. We don’t want to wait six months for the next release. I certainly understand other deployers won’t want to deploy as rapidly as we do, but they can always skip releases. If there is only one release every six months, folks like us at Rackspace have nothing to deploy unless we just “release” it ourselves.
If we always keep a working trunk, why not release it once it has a significant amount of change (new feature, bug fixes, security patch)?
From the parallel discussion we’ve been having on Twitter, I think we can resolve most of the difference in opinion 🙂 We both agree that Swift benefits from being released often… I think the remaining confusion is on the word “release”. It’s confusing because there is no single type of “release”. For OpenStack projects we decided to have three distribution channels: the trunk builds (at every commit), the milestones (~ every month), and the common release (every 6 months).
Depending on the specific project, those different types of “releases” are more of less QA-ed and more or less usable in production. I think that Swift “milestones” can definitely be used in production, given the stability of the product and the fact that you apply good QA effort for each of those. So, in essence, you can recommend “milestones” to be the “production releases” for Swift. The common release every 6 months just happens to be coordinated with other OpenStack projects, it is not better or worse for production usage. We kinda already acknowledge that by giving each milestone its own Swift version number.
So I think we essentially agree on frequency. Where we still don’t agree, I think, is that you prefer frequent feature-based releases, and I prefer frequent time-based releases. My argument being that you bring visibility to the rest of the stakeholders, without creating a significant gap in the feature delivery, so the benefits outweigh the costs.
Looking at http://wiki.openstack.org/DiabloReleaseSchedule, it’s rather obvious that Swift development would not have suffered if it released at the same dates as Nova and Glance. However, not knowing in advance when the milestones will hit in the next months is a bit of a plan-ahead pain for me, and I’m sure for others as well.