David Waite wrote:
> +1, release early, release often.
This mantra, cute as it is, neglects the costs of releasing *too* often.
You can release early and often all you want with patch releases, but minor
releases come at a price -- more branches to maintain, more versions of
oft-changed APIs, etc.
I think historically we've done a good job of finding a good balance here.
And yes, judging from said history, it would appear we're about due for
another minor release.
But here's my concern. Of the features in the trunk so far that Hyrum as
touted, I don't really see any that strike me as Big Ones Most Everyone Is
Clamoring For. I don't say this to diminish the features or the fantastic
work of those that provided them, but compared to Merge Tracking, they all
seem to fill somewhat niche-y voids applicable to relatively small sets of
So here's a counterproposal -- rather than continuing the recent trend of
fifteen Subversion committers all working on a individual features by
themselves, why don't more of the committers try directing a group effort at
the Merge Tracking problem (the Big One Most Everyone Is Clamoring For)? No
harm can come from having more eyes on the problem. And it's possible, just
possible, that we can improve its delivery date in the process, if only by
improving the quality prior to the release stabilization period.
C. Michael Pilato <firstname.lastname@example.org>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Mar 8 18:14:50 2007