Re: Beyond GCC 3.0

["H . J . Lu" <hjl at lucon dot org>]

On Thu, Jun 28, 2001 at 06:58:02PM +0100, Joseph S. Myers wrote:
> On Thu, 28 Jun 2001, H . J . Lu wrote:
> 
> > >   - Do bug fix releases two and four months after the major
> > >     releases, as required.
> > 
> > Unless I am mistaken, I don't think there should be a time constraint
> > on the bug fix releases. We know any gcc releaases can't be bug-free
> > for everyone. Every gcc release has bugs, some of which are critial to
> > some people. If we can make the bug fix branch relatively stable, what
> > is wrong to make a bug fix release everytime when there are enough bug
> > fixes checked in? Sure, it may have new bugs. But it does fix some old
> 
> Also, where in this scheme do bug fix releases to older major releases -
> such as 2.95.4, if it happens - fit in?  Are they just done when
> appropriate if someone volunteers to be release manager for them?

For the older releases like 2.95.x, unless there is a regression over
egcs, I don't see a need for 2.95.4, assuming we will have a gcc 3.0.x
which

1. Doesn't have any regression over 2.95.x.
2. Fix the bugs which are supposed to fix in 2.95.4.

The idea is we spend time to make sure a new stable release can replace
the previous stable release. But if we cannot make gcc 3.0.x to do #1
and #2 within, say, 2-4 weeks, all bets are off. BTW, that is what I
have been doing with the Linux binutils. When people reports a bug
against the older version of the Linux binutils, I ask them to try
the current release. I will make sure it will work for them. Sometimes,
it means I have to make a new release to fix a regression or a bug.


H.J.