Jani Averbach <firstname.lastname@example.org> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jun 20 05:05:09 2005