Once upon a time, we had a release policy [1]. It said that releases
would be roughly time-based, that each release would include at least
one new feature or "significant differentiator", but that we wouldn't
say specifically which feature it would be. Whatever's ready when the
date arrived could be the release definer. It wouldn't matter so much
*what* the feature was, as long as there was one. After all, what
doesn't get shipped in this release would just get shipped later.
Unfortunately, we ignored this policy for 1.5.
Instead, we decided that Merge Tracking would define the release.
Then we delayed the release as long as necessary to get basic Merge
Tracking into it, even though other features were ready earlier
(WebDAV proxy, sparse directories, etc), or could have been ready if
we hadn't felt such mad pressure to finish Merge Tracking because we
decided that it -- and nothing else -- would be the release definer.
Can we please, please do things the other way for 1.6?
Let's say "1.6 will come out approximately six months after 1.5, and
whatever is ready will go into it." If improved tree-conflicts are
ready, great. If reflective merges are ready, great. If something
else is ready, great. But -- and here's the important thing -- if
only *one* thing is ready, the release should *not* wait for any other
thing. At six month windows, the price of delaying a not-quite-ready
feature is not so high, and when it does come out it will be mature.
As it was, we paid both coming and going for our indiscipline: because
we refused to release 1.5 for so long, we finally had to compromise on
some parts of Merge Tracking in order just to ship.
I know these are not new thoughts; Justin recently posted saying the
same thing. I just thought I'd point out that we wrote up this policy
years ago, and pretty much all thought it was a good idea, and then we
ignored it anyway. We can stop ignoring it any time we want :-).
-Karl
[1] http://subversion.tigris.org/roadmap.html#release-planning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 22:33:10 CET