What follows is my summary of a conversation held today at the Hackathon around reducing Subversion's lengthy (and unpredictable) release cycles.
Universally, attendees expressed interest in shorter, time-based release cycles. The sole reason stated provided for feature-driven releases was for the purpose of always showing demonstrable progress on our users' needs (for example, merge tracking), but we generally agreed that this is primarily a communications problem. Much discussion occurred around the mechanics of branch-based feature development, the possible introduction of APIs marked “experimental”, and the ever-present necessity of getting eyeballs on features early while still wishing to keep the trunk trending toward relative stability as the end of the time-based release cycle approaches. Not much here was said that hasn't been said before, so I'll not rehash the full collection of arguments. That said, the following is the joint recommendation of the hackathon attendees. In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. In the second three months, we will still accept smaller new features. But at the end of the six months, the trunk is closed to new features and stabilization for the release begins. We will allow up to three months for stabilization on the trunk, cutting the release stabilization branch at the end of the period (or beforehand, if we agree that the codebase is ready for RC). The release branch is managed the same as it is today, with an RC at the earliest reasonable moment and the same soak requirements and such that we've always had. Some open questions remain, namely: What affect should this have on long-term maintenance of our release lines? There was some support for the idea of moving to time-based support cycles here, too, rather than our current approach of maintaining the most recent X.Y release only. Shorter release cycles should lead to (smaller-impact) releases more often, but adopters will realistically not absorb every single Subversion release. It might be beneficial to say that we'll continue to maintain X.Y releases for a period of, say, two years from their .0 release date. (We can, of course, choose to patch even older releases for security or other high-impact fixes, of course – it's only our minimal promises that we're talking about here.) Should we require vote-based approval on the reintegration of feature branches? At least some of the hackathon attendees favor the typical “three +1's and no vetos” – the room was not polled for general consensus here, though. Proponents claim that this both helps to solve the inherent dangers of code bombs (it minimizes *cognitive* destabilization) and also encourages feature composers to do a better job of vetting their designs in advance so as to a) ignite interest and attention and b) reduce the chance of widespread disapproval of the feature or the approach taken. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
