Subversion release planning.

[kf...@collab.net]

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

Re: Subversion release planning.

[kf...@collab.net]

Branko Čibej <br...@xbc.nu> writes:
> >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.
>
> Isn't this exactly what we've been doing?

Not really.  For 1.2, for example, we promised for ages and ages that
locking would be the big feature.  We kept that promise, somewhat at
the expense of 1.2's release date IIRC.

Under the new proposal, 1.2 could have come out sooner, with some
other feature if it was ready, and locking would have come out in 1.3
instead.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion release planning.

[Branko Čibej <br...@xbc.nu>]

kfogel@collab.net wrote:

>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.
>  
>
Isn't this exactly what we've been doing?

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion release planning.

[kf...@collab.net]

Jani Averbach <ja...@jaa.iki.fi> writes:
> > 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.
> 
> Do you mean by "trains" minor number, eg. 1.X.0?  If so, what will be
> a support time span for older versions?  Let's say 1.1.x or 1.2.x
> line?  At one point we had this discussion, and I think that the
> consensus was that version 1.(X-2) is unsupported. So, if there is a
> new minor version every 3-4 months, I think that we should extend our
> support period, which will, on the other hand, cause more burden for
> the project.

Right, I meant the minor (middle) number.

I don't think it's that much extra burden for the project, in reality.
For example, we just recently stopped "supporting" the 1.0.x line.
Mainly this means that we won't be putting out any more 1.0.x micro
releases.  But we had mostly stopped doing those anyway, because no
bug serious enough had come along to justify one.  With this new
system, we'd be adding at most one more window (X-3 instead of X-2);
whether that actually results in more micro releases in practice is
hard to say.

As far as accepting bugs goes, there is very little extra effort.
Look at our standard process today:

   - The first thing we usually do is ask someone to reproduce with
     head of trunk anyway, or if the reporter can't try it, then we
     try it ourselves.

   - Even if we receive a report against an unsupported version, we
     *still* try to reproduce against head of trunk if we suspect the
     bug might be in the current sources.  This would not change.

IOW, I don't think that what we actually *do* will change very much.
The thing that will change will be the labels we give the work, not
the work itself.

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion release planning.

[Jani Averbach <ja...@jaa.iki.fi>]

On 2005-06-17 16:43-0500, kfogel@collab.net wrote:
> 
> 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.

Do you mean by "trains" minor number, eg. 1.X.0?  If so, what will be
a support time span for older versions?  Let's say 1.1.x or 1.2.x
line?  At one point we had this discussion, and I think that the
consensus was that version 1.(X-2) is unsupported. So, if there is a
new minor version every 3-4 months, I think that we should extend our
support period, which will, on the other hand, cause more burden for
the project.

BR, Jani

-- 
Jani Averbach

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion release planning.

[Julian Foad <ju...@btopenworld.com>]

kfogel@collab.net wrote:
> 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.

+1.  This makes perfect sense to me.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org