Re: State of maturity for gcc 2.95.3 and gcc 2.96

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Gerald Pfeifer wrote:

> On Sat, 14 Oct 2000, I wrote:

> > E.g., we define a release branch; hammer on it until it is "bug-free"
> > (hah :-) and subsequently have weekly snapshots from _that branch_
> > called GCC-3.0.n which are our "stable releases".

> I see some problems with this approach:

>  1. We will have a new release snapshot even if there has been no change.

I think the shell script(s) constructing the weekly snapshot-from-
release-branch can be made intelligent enough to only produce one if
something has changed on the release branch.

>  2. Consistency: Right now we can assume that most people use one out of a
>     few version of the compiler, as do GNU/Linux distributions.

But changes on the release branch are only fixes !  Surely, we might
sometimes run into the problem of having to scan the ChangeLog to see
when some bug was fixed (i.e. between which two snapshots), but that's a
minor issue, AFAICS.

>     If we update once a week, would distribution upgrade every week as
>     well?

No, why ?  Distributions should update when they think such necessary. 
After all, the alternative is to include fixes themselves ("by hand").
In fact, just as with snapshots from the trunk, we cannot actually
prohibit someone building a distribution using a snapshot ... I'd rather
have them use a snapshot from the release branch than from the trunk.

>  3. Quality: Even for .point releases we probably want to do some quality
>     control, e.g. by volunteer testers, where we mention (on a web page)
>     whether some snapshot has been tested and, if so, how it fared on that
>     platform.

I don't think bug fixes should have to be severely tested.  A mandatory
build+check on a couple of widely different architectures per fix should
be sufficient.  After all, we don't apply bug fixes to the release
branch lightly now, too.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)