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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-06-13 15:27:49 CEST