Re: Stable releases

[Neil Jerram]

Rob Browning <address@hidden> writes:

> If we maintain the stable tree such that we only commit *very*
> conservative changes, then the need for wider testing should be
> substantially diminished.  However, with 1.8, I think we've been more
> liberal (allowing new features, etc.) than we were with 1.6.  Whenever
> we're very conservative, the longer advance warning shouldn't be as
> necessary, but it shouldn't hurt either.

Agreed.

Because of this discussion, I've been thinking through what we mean by
a stable release, and whether we have taken a wrong turn in deciding
to try to release more stuff earlier by merging from HEAD into 1.8.x.

I think we probably have taken a wrong turn, because I don't think the
1.8.x that we are on the verge of producing can be described any more
as a "stable" series.  Surely the common connotations of "stable" are
that the API is as unchanging as possible, and that the code is only
changed in order to fix non-trivial bugs?

And on the other hand, if 1.8.x isn't a "stable" series, how does it
differ usefully from HEAD?

Therefore, my feeling now is that we should revert to traditional
"stable" handling for 1.8.x.  This would mean not merging enhancements
from HEAD such as my debugging stuff and Ludovic's text collation
work.  It would also mean that Rob's comments about limited testing
requirement hold.

As far as releasing exciting new stuff is concerned, I suggest we just
make unstable 1.9.x releases every now and then.  We should flag these
very clearly as unstable, and not really worry at all about testing
them.

> In any case, assuming I'm going to continue to be the nominal release
> manager, then I'd be likely to send advance notifications to the list.
> Of course, I don't have to be the only person handling releases,
> though there may be some benefit to having one person familiar with
> the process coordinating things.

We certainly need at least one familiar person, but I'm sure it would
be even better to have more than one.

> On the other hand, if we make sure that the stable release process is
> well documented, and if we make sure to check with each other before
> making a release, then we might not really need an official release
> manager.  That could help share the work, and avoid a single point of
> failure.

Yes, I think that would be better.  But we all have a lot to learn
from you first!

Regards,
     Neil