Re: GCC 4.2.0 Status Report (2007-02-19)

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Mark Mitchell wrote:
> I've heard various comments about whether or not it's worth doing a 4.2
> release at all.  For example:
[...]
> So, my feeling is that the best course of action is to set a relatively
> low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
>       Then, we'll have a 4.2.0 release by (worst case, and allowing for
> lameness on my part) March 31.
>
> Feedback and alternative suggestions are welcome, of course.

The 4.2.0 release is fairly significant to GFortran.  In my opinion, 
it's really the first 4.x release for which we have a mature Fortran 
compiler -- while 4.1 is a big improvement over 4.0 (which we pretty 
much officially recommend against using, at this point), it's missing 
quite a bit of functionality and a lot of bugfixes that only made it 
into 4.2 and 4.3.

In addition, the GFortran team has put a good bit of work specificially 
into the 4.2 branch, and in backporting fixes to it after the 4.2/4.3 
split.  I think it's important to consider that creating the branch is 
not just a commitment to our userbase; it's a commitment to the 
volunteers who put time into working on it.

Thus, I would find the option of discarding the current 4.2 tree in 
favor of an "upgraded" 4.1 tree to be extremely disheartening; not only 
does it discard the GFortran work done on the 4.2 branch, but it also 
releases a Fortran compiler that is significantly inferior to what's 
currently in that branch and what we've been promising.  (Backporting 
the fixes is sufficiently impractical to be out of the question.)

I also think that it would be unfortunate to replace 4.2 with a copy of 
4.3.  Besides the fact that it discards lots of work, the extra time 
that it will take to get a release ready means that much more time until 
the new stuff makes it into a released version, and IMHO we've been 
telling people "the released versions are way out of date; use a 
development version" quite long enough.

Thus, from a GFortran perspective, I am very strongly in favor of the 
proposal to fix the P1s in the current 4.2 branch and ship it.

- Brooks