This is the mail archive of the
mailing list for the GCC project.
Re: Criteria for GCC 4.0
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 05 Jun 2004 00:07:00 +0200
- Subject: Re: Criteria for GCC 4.0
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <email@example.com>
firstname.lastname@example.org (Zack Weinberg) wrote on 04.06.04 in <email@example.com>:
> firstname.lastname@example.org (Kai Henningsen) writes:
> > email@example.com (Phil Edwards) wrote on 02.06.04 in
> > <20040602190903.GA29825@disaster.jaj.com>:
> >> I'm not arguing for /never/ having a 4.0 release (although others do take
> >> that position, and it's a reasonable one).
> > I'll say here that from where I sit, that doesn't strike me as
> > particularly reasonable. More like the opposite.
> It follows logically from the position that a 4.0 version number would
> only be justified by actions we would never take.
Which says to me that it's an unreasonable position.
To me, a position that says "never 4.0" is pretty much unreasonable by
definition. The only reasonable argument for that would be that the code
in question has reached the end of development and is, effectively, dead.
To put it in different words, when you say you'll never be releasing a new
version of 2.95, then the 2.95 branch is dead. When you say you'll never
release a 2.x version with x > 95, then gcc 2 is dead. When you say you'll
never release a gcc x.something with x > 3, then gcc as a whole is dead.
And the argument "only use a new major if we break something" sounds both
contrived and silly to me.
> I had considerable difficulty thinking of changes to GCC that would
> justify a 4.0 version number to me. Here are two (and I hope everyone
> agrees that we'd never do either):
> - Dropping support for the C language (because everyone uses C++
That certainly doesn't sound like a good reason for 4.0 to me.
> - Redesigning the machine description language, only updating the
> x86 backend to match, then doing a release before anyone has had
> a chance to update other backends.
Nor does this.
> And for the record, I now think the 2.95->3.0 version number bump was
> *only* justified in order to extract ourselves from the corner we'd
> painted ourselves into because EGCS internally considered itself to be
This would be borderline.
Whereas I thing tree-ssa and f95 look like reasonable arguments.