This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC version bikeshedding


On 7/23/2014 11:20 AM, Ian Lance Taylor wrote:
> On Wed, Jul 23, 2014 at 3:28 AM, Jason Merrill <jason@redhat.com> 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
break
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
dropping
to two digits. Which do you all think is greater?

Also, what about any software that used __GNUC__, __GNUC__MINOR__, and
__GNUC_PATCHLEVEL__?  

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
convinced.

--joel

> Ian

-- 
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]