Re: GCC version bikeshedding

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jul 23, 2014 at 9:42 PM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
>
> 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?

Actually I don't care too much.  But yes, just to clarify, the proposal
was to drop the patchlevel from the visible version numbering scheme,
thus release 5.0, not 5.0.0.

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

__GNUC_PATCHLEVEL__ will of course stay, just it's value will not
provide any information anymore.

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

None (see above).

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

It won't impact that at all.

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

Huh?  Bug fixes from the gcc-5-branch (heh, not gcc-5_0-branch) will
be done as usual, just numbering as 5.1, 5.2, 5.3 ... instead of
5.0.1, 5.0.2, 5.0.3.

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

Nothing will change but removing one piece of the version.  Technically
it will be the patchlevel but in reality it's the major number that goes
away - think of releasing 4.10.0 but calling it 10.0 instead (dropping
the "4." part which didn't carry any useful information during the last
10 years).  Of course going from 4.9.x to 10.0 is stupid (heh, but
would be a nice marketing trick!), so we go from 4.9.x to 5.x to 6.x.

Richard.

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