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

Subversion release planning.

From: <kfogel_at_collab.net>
Date: 2005-06-17 23:43:14 CEST

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

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

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.



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

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.