[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge-tracking and svn 1.5

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-12-15 21:02:30 CET

Erik Huelsmann wrote:
> On 12/15/06, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>> On 12/15/06, Lieven Govaerts <svnlgo@mobsol.be> wrote:
>> > When is 1.5.0 scheduled for release?
>>
>> Whenever it's ready. =) -- justin
>
> Which is *exactly* the reason why I don't like the strict coupling
> between features and releases...
>
> Our release process has been far from optimal since 1.2 and I was
> hoping to propose small releases to make releasing less hard. Seeing
> the discussion here makes me believe all of you are headed exactly in
> the oposite direction. How much harder do you want it to become to get
> a release out the door?

The idea of smaller, more-often releases may sound appealing at a high
level, but don't forget to factor in the fact that with greater density
of releases comes the following undesirables:

   * a greater push to keep more of those release streams active (so we
     don't over-burden sysadmins with the need to upgrade), which means
     more maintenance overhead. Today we basically keep two release
     streams alive. If that increases to three or four, there's more
     work there.

   * potentially shorter time in the limelight for revved APIs. Our
     longer release cycles allow us to bundle multiple changes to the
     same API into a single rev of that API, which reduces maintenance
     overhead.

I'm not voicing an opinion about the release process either way -- just
want to make sure that we consider things fully.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Fri Dec 15 21:02:46 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.