On 3/8/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> 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.
Well, yes - and it was said risking that I would would be made to actively
help prepare one or more of the said releases as a result ;-)
> 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
> users.
My concern is just one of dates. 1.4.0 was announced September 10th, two
days shy of six months ago. I hear that merge tracking would be in,
hardened, tested and ready for release another six months from now - and
this is indeed a 'hard' feature, and there is always the possibility it may
take longer.
So as one who does not actively work on creating a release, let me instead
represent the process of creating another new minor release as a one month
delay in development. So, would I rather have 1.5 in April and 1.6 with
merge tracking in October? Or no minor release at all until September, one
year since 1.4?
> 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.
My opinion also changes based on whether merge tracking has six months,
three months or six weeks left to be complete and stablized. I'd hate to
have to wait for merge tracking just because there aren't any other features
ready to go for 1.6, or because the releases would be a mere three months
apart. It is not a great place to be, having arguably the biggest feature
addition since 1.0 stuck straddling the release timeframe.
As far as eyes go, I have two I can donate to getting this feature
solidified faster. I have a perforce -> subversion migration I'm pushing for
that could get held up politically by the lack of merge tracking.
Received on Fri Mar 9 07:32:17 2007