This is the mail archive of the
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Ian Lance Taylor <iant at google dot com>, Jason Merrill <jason at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 23 Jul 2014 14:42:31 -0500
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <20140720165506 dot GT3003 at laptop dot redhat dot com> <7564e4f5-8030-4a23-8b0b-b1262265a349 at email dot android dot com> <20140720170146 dot GU3003 at laptop dot redhat dot com> <53CF8E48 dot 8090003 at redhat dot com> <CAKOQZ8yvTaos4Qo=cBEF070_rZkF9V-2L-76R6i7KLisBMEn-g at mail dot gmail dot com>
On 7/23/2014 11:20 AM, Ian Lance Taylor wrote:
> On Wed, Jul 23, 2014 at 3:28 AM, Jason Merrill <firstname.lastname@example.org> wrote:
>> On 07/20/2014 06:01 PM, Jakub Jelinek wrote:
>>> On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote:
>>>> I understood we agreed on 5.0 and further 5.1, 5.2 releases from the
>>>> branch and 6.0 a year later. With unspecified uses for the patch level
>>>> number (so leave it at zero).
>>> Ian/Jason, is that your understanding too?
>> I didn't think that we had come to a decision, but I don't mind going ahead
>> with this pattern.
> I am also fine with it.
> I think that if anybody has strong objections, now is the time to make
> them. Otherwise I think we should go with this plan.
> To me, the basic summary of the idea is that there is no clear reason
> to ever change the GCC major version number. There were real
> objections to changing it when we went from 3 to 4. There will be
> real objections for any future change from 4 to 5. At the same time,
> we face the fact that going from 4.9 to 4.10 will break some people's
> existing scripts, as is also true of any other decision we can make.
But don't we also face the fact that dropping the third digit will also
scripts? The fact that the version number has 3 parts now and will move to
2 is a more fundamental change that NUMBER.NUMBER.NUMBER. Anyone
who assumed that each NUMBER was a single digit made a worse assumption
than someone whose pattern had three non-negative integers separated
by a period.
So there is a risk of buggy script/packaging code for going to 10 or
to two digits. Which do you all think is greater?
Also, what about any software that used __GNUC__, __GNUC__MINOR__, and
The first piece of non-gcc code I thought of impacted was <sys/cdefs.h>.
This is from FreeBSD: http://fxr.watson.org/fxr/source/sys/cdefs.h which
is what the version in newlib is based on.
The Linux version appears to have similar checks.
How much impact to existing non-GCC code is this going to have?
> Given that there is no clear reason to ever change the major version
> number, making that change will not convey any useful information to
> our users. So let's just drop the major version number. Once we've
> made that decision, then the next release (in 2015) naturally becomes
> 5.0, the release after that (in 2016) becomes 6.0, etc.
I didn't think I had much of an opinion but am beginning to wonder how this
will impact feature freezes, periods for big changes, and bug fixes.
The nice thing about the 3 number version is that GCC had bug fixes itself
in the FSF source on branches as the third digit incremented. I know from
years of experience that it has usually taken until .1 or .2 to get all the
RTEMS targets assuming the target itself isn't horribly broken. And that
the head may be broken in a completely different way.
Maybe I missed something but the idea of point releases with just bug
fixes from the FSF source seems to be missing.
Personally, I am not convinced this is a good idea. If it really is, then
the risk to third parties, GCC feature integration timing, and stable
branch support, needs to be accounted for. I am open to being
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985