On Sun, Jan 29, 2006 at 02:23:30PM -0600, kfogel@collab.net wrote:
>...
> One advantage of the shorter release schedule (appx every 4 months) is
> that when a release encounters unpredictable delays, it still only
> puts us out at 5 or 6 months, instead of 7 or 8. And if we don't
> encounter delays, so much the better.
The question/problem under discussion isn't about when users see the
release, but how long features have for development before they get
into a release. With a short cycle and a standard soak, then there is
*very* little time for feature development.
> We've already heard from administrators who prefer more frequent
> releases, and those who prefer less frequent ones. There's never
> going to be a clear answer on that one, because different admins have
> different needs.
Right. IMO, I would take that to mean: continue on our current path
and get some good work done before releasing. There is always going to
be "something cool" in the pipeline. So that effectively means an
early release is going to cut something out. Of course, it is a race
condition, so something will *always* be cut out, but allowing more
time for development allows us to provide more features/reasons for
people to upgrade. It provides some sense of stability in a tool that
is critical to most companies' work, rather than throwing them onto a
rapid upgrade cycle.
> As far as getting the serf changes into 1.4: isn't this committing
I'd prefer if we detach the policy discussion from serf. Regardless of
what Justin gets done, there is no way that serf would be the default
DAV implementation for 1.4. Thus, it is a non-starter to really talk
about serf as a feature for 1.4. Let's just skip that for now.
>...
So. In short, I'd rather see a slower and more methodical release
strategy than a cool-feature-of-the-day shortened release cycle.
Cheers,
-g
--
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 Sun Jan 29 23:26:37 2006