I'd like to propose a new way to schedule Subversion releases.
The way we've been doing it hasn't been working out very well, I feel.
We've tried to be both time-driven and feature-driven simultaneously.
For example, we try to plan Subversion 1.3 for a certain date, *and*
we say that it will have new features X, Y, and Z. But then feature X
(say, log message templates) takes a lot longer than expected to
design, and maybe expands to include other features (say,
server->client autoprops), and all of a sudden we are forced to either
delay the release, or drop the feature that we said would be in it.
The two most obvious solutions are a bit dissatisfying...
Solution A -- Be Purely Feature-Driven:
Stop anticipating dates for non-micro releases. But that's not
good. For one thing, it helps focus us to have releases coming
out. Also, sometimes feature Y is unexpectedly ready before
feature X, and why should we delay Y's availability just because we
foolishly said X would be the release definer for the next release?
Solution B -- Be Purely Time-Driven:
Just aim to release on a given date, and if we happen not to have
any new features, that's okay. But that's not good either, because
we already *have* bugfix lines (1.2.1, 1.2.2, etc) for that sort of
thing. When 1.3 comes out, users expect it to be distinguishable
from a micro release: it should offer something new, beyond just
fixes.
Neither A nor B really seems right. What I'd like to propose instead
is a more flexible model, that would allow us to make predictable
releases while not cramping new feature design discussions.
Solution C -- A Lovely Compromise:
Aim to release around a given date, and say that the release will
contain one or more new features (or significant differentiators)
from the previous maintenance line -- but do not promise any
specific new feature. Of course, we can still aim to have certain
things done by a certain release, but the point is that a release
can still go out the door without those things, as long as there's
*something* present to justify the release.
So for example, if log message templates are ready for 1.3, that would
be enough to justify the release. Or if server->client autoprops are
ready, that would be enough. Or if the first stages of repository
rename support are ready, that would be enough. (As it happens, I
think even just the resolution of issue #1709, which is fast upon us,
would be enough, because it would be such a usability win. But the
point is that we don't have to decide which feature is going to be the
decisive factor in advance.)
When some important feature is really close, we can discuss delaying
the release, on a case-by-case basis. But we wouldn't be tempted to
do that very often, because part of the point is to make releases more
predictable. This is sometimes known as the "release train model".
The idea is, trains leave the station at regular intervals. If a
given feature doesn't make it onto this train, that's fine. The
feature will be ready by the time the *next* train leaves, which won't
be very long -- because we're predictable. The actual interval I'm
shooting for is 3-4 months, though that's certainly open to
discussion.
Our roadmap page would explain all this. It would show both the
planned release dates, and show the features currently under
discussion (with links to discussion threads and issues). But the
page would make it clear that two are only loosely connected. So
people would see when the next release is coming out, and have a sense
of what features are being worked on currently, yet the project would
avoid crippling commitments to jam a specific feature into the next
release before that feature has had time to mature.
I feel like reorganizing along these lines will free us up to have the
autoprops/log-message-templates/iprops discussion we need.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 18 00:26:41 2005