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

Re: Release targets and timeline for 1.4?

From: Greg Stein <gstein_at_lyra.org>
Date: 2006-01-28 04:35:14 CET

On Fri, Jan 27, 2006 at 11:18:57PM +0000, Julian Foad wrote:
> >it means that features ready at branch-time
> >will now have to wait until 2007.
> Now you've really lost me. It sounds like you're exaggerating because you
> feel aggrieved that I was unfair. I tried to be fair; sorry if I seemed to
> go on about the negatives and didn't say anything or enough in praise and
> confidence of your work.
> I respect you as a developer, Justin, and believe you'll make a good job of
> this and reasonably soon.
> But I really can't believe you meant that sentence literally; if you did,
> please explain - especially "ready" and "2007".

Heh. You said it yourself at the bottom of this reply. That if
something doesn't get into 1.4 in the next month, then it will have to
wait for 1.5, and you said "January 2007". That's what Justin is
referring to. Nothing about bad feelings, just how people are setting
the dates on the releases.

> >As we've talked about at length before, doing minor releases more than
> >twice a year is a bad and confusing thing for users. IIRC, I believe
> >Greg Hudson and I debated this a long time ago, and now I see the
> >wisdom in his comments and now support slower release cycles.

For something like version control, I would tend to think slower
cycles also, and would support a six-month cycle. What kind of
confidence can we give people if we are continually making new
releases. "Woah? What was wrong with the last one? They're making a
new release again?!"

Though hearing from "real" admins like Lieven, that can certainly
alter that viewpoint.

For myself, I only recently upgraded my SVN server from 1.0.3 to
1.3.0. There just isn't a need for staying on the version treadmill
and upgrading it every time a new release came out.

> If we can't find an archive of that discussion, maybe we'll have to have it
> again. Obviously there is merit in that approach, but I get the impression
> the shorter release cycles are more generally favoured.

I'm not so sure. I've seen a few asking for it, but there hasn't been
a lot of discussion on this yet. The notion of a short cycle only came
up on this list recently, and only then because I heard about it in
person. I don't recall seeing anything on-list before then (tho I
think somebody said the idea was broached in IRC).

We still have time for discussing what the overall release goals of
the project are: on the whole, do we want fast or slow cycles?

I tend towards slow, especially given our soak time requirements. That
is just too much overhead to absorb in a fast cycle process.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 28 04:31:08 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.