Greg Stein <gstein@lyra.org> writes:
> 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.
Hmmm, that I don't quite get... A feature can be developed across two
or more minor cycles, if it doesn't fit into one... ?
> > 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.
But not everyone wants "more features/reasons for people to upgrade" :-).
Some people want only one new thing per release -- they find *that* to
be the more "stable" approach. Such people often don't feel the need
to upgrade with every release; they may do every two, or even three.
(Seems you started out saying "Right", in agreement with my paragraph,
but then went on to argue for only one side, whereas what I was trying
to say is that there are two somewhat symmetrical sides: it's not
objectively the case that one or the other way is more/less stable or
more/less conservative. Are releases that come less often, but
involve bigger changes, more "stable" than releases that come more
often, but with less churn per release? That's a tough one.)
In any case, I'm not sure how changing the dates at which releases get
made allows more or less time for new feature development. A feature
takes as long as it takes; however many releases happen during that
time won't change the feature's development time.
> 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.
Agreed.
> So. In short, I'd rather see a slower and more methodical release
> strategy than a cool-feature-of-the-day shortened release cycle.
I'd prefer to base the schedule on the features, rather than the
reverse. In other words, take a look at what we've got on the plate
for 1.4 right now, see if it's attractive enough to warrant a new
release, and base our decision on that.
There may be discussion around what "attractive" means, when applied
to new features, but maybe that's a more useful discussion for us to
have than talking about release dates in the abstract.
This is why I liked Garrett's and David James' mails, because they
concentrated on the content of the release, and made the date
contingent on that. The slate of improvements, with svnsync as the
big new feature, seemed like easily enough change (read: churn) to me.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 30 00:14:20 2006