This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32
- To: kenner at vlsi1 dot ultra dot nyu dot edu
- Subject: Re: Problem w/PIC and C++ exceptions in 2.95 on IA-32
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Thu, 27 Jan 2000 21:28:20 +0100
- Cc: egcs at egcs dot cygnus dot com
- Organization: Ecole Normale Superieure de Paris
In article <10001271231.AA17582@vlsi1.ultra.nyu.edu> you write:
> > FreeBSD and others actually track the gcc-2.95 release branch of
> > CVS, so it matters to people even if we do not produce a formal release.
>
> IMHO, the GCC Project may find that more and more people do this also.
>
>To me, this seems a bad thing to do. If we don't actually produce a formal
>release, that branch isn't going to get much testing, so I'd be very dubious
>about people using it as the base for other releases.
I agree.
Now, let's sum things up.
On the one hand, only important bug-fixes are put on the old release branch.
On the other hand, this branch does not get serious testing if no release
is produced with it.
Well, for me, the conclusion is obvious:
the presence of new fixes on the 2.95 branch since 2.95.2 means 2.95.3
should go out, and soon !
The only reasons I see for things not to be so are:
* working on 2.97 already (hum, one can hope).
* wanting to avoid the `release of the day' syndrome.
2.95.2 is already 3 months old. If those bug-fixes are serious enough
to be in the 2.92 branch, I'd say this is old enough.
Out of curiosity, what schedule would you consider reasonable for bug-fixed
releases ?
Personnally, I would tend to say 2~3 months is about right... considering
that a bug-fixed release is less work than a full release (diminishing
returns: after a while, the number of critical changes will decrease
drastically, as will the likelihood that a bug-fix triggers other untraceable
bugs.