Subject: Re: Release cycles (Was: Re: RealAudio)
To: The Grey Wolf <greywolf@starwolf.starwolf.com>
From: Colin Wood <cwood@ichips.intel.com>
List: current-users
Date: 11/03/1997 01:50:48
The Grey Wolf wrote:
> 
> This may sound kind of wacky, but how about the concept that between
> releases M.m and M.(m+1), the "interim releases", i.e. M.m.X, the X
> doesn't have to be all inclusive or sequential.
> 
> Say, for example, you see
> 
> 1.3
>         1.3.1/SPARC
>         1.3.2/SPARC
> 
> and then the pmax (or whatever) is ready for an interim release.  You could
> call it 1.3.1/pmax because it was the first release, but I think to skip
> .1 (since there was no .1 ready at the time of 1.3.1/SPARC) would be a
> wiser idea, since then you wouldn't have to map version numbers, and
> you wouldn't find yourself wondering, "gee, does 1.3.1/pmax map to
> 1.3.3/SPARC or is that the other way around?"
> 
> Whadaya think...?

This sounds like a good idea (especially on ports like mac68k where _so_
much support is added between releases), until you dig a little deeper and
realize what a release engineering nightmare you'd be getting into.  The
current method (i.e. all ports do bugfix releases at the same time)
provides several benefits:

1) A release engineering team exists (well, more or less) to oversee the
process and can be responsible for making sure that the release works on
all ports

2) The source tree only has to be branched/tagged/etc. once for all ports

3) All ports see consistency with respect to common userland binaries

4) All ports can benefit from changes/fixes in the MI portion of the
kernel.

I'm sure there are more, but the above should be sufficient for my
argument.  If we instead split bugfix releases among the various ports,
we'd have many disparate branches which would have to be tracked and
maintained.  Much of the release-engineering work would be put on the
portmasters, as would support following the release.  Ports which didn't
make a particular bugfix release would not benefit from the latest fixes
to things like sendmail or the vm system.

So, I think it's probably better that we stick with the "all or none"
method that we currently employ.  However, we could use more frequent
major releases and regularly scheduled bugfix releases.  Many people have
discussed this off and on for the past year and many have tried to plan
for ways to achieve this.  Only time will tell how successful their
efforts are :-)

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.