[google] Normalize version number for google/gcc-4_6 (issue4454049)

[google] Normalize version number for google/gcc-4_6 (issue4454049)

[Diego Novillo]

Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.

Fixed with this.  OK for google/gcc-4_6?

	Google ref 4335466.

	* BASE-VER: Change to 4.6.x-google.

diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index 4110f74..33d4edd 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-4.6.1-google
+4.6.x-google

--
This patch is available for review at http://codereview.appspot.com/4454049

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Ollie Wild]

On Mon, May 2, 2011 at 2:53 PM, Diego Novillo <dnovillo@google.com> wrote:
>
> Since google/gcc-4_6 follows the 4.6 branch, changes in minor
> revisions cause unnecessary churn in directory names.
>
> Fixed with this.  OK for google/gcc-4_6?

Yes, okay for google/gcc-4_6.

Thanks,
Ollie

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Matthias Klose]

On 05/02/2011 09:53 PM, Diego Novillo wrote:
> Since google/gcc-4_6 follows the 4.6 branch, changes in minor
> revisions cause unnecessary churn in directory names.
>
> Fixed with this.  OK for google/gcc-4_6?
>
> 	Google ref 4335466.
>
> 	* BASE-VER: Change to 4.6.x-google.
>
> diff --git a/gcc/BASE-VER b/gcc/BASE-VER
> index 4110f74..33d4edd 100644
> --- a/gcc/BASE-VER
> +++ b/gcc/BASE-VER
> @@ -1 +1 @@
> -4.6.1-google
> +4.6.x-google

is this enough? the subminor version number is encoded in more places, e.g. C++ 
headers, Go libraries, jar files.  For the Debian/Ubuntu packaging I'm just 
using symlinks from 4.6.x to 4.6 to avoid this kind of dependency.  Now that the 
-V option isn't supported anymore, maybe this could be addressed with something 
like a new configure option --version-alias=<value>, similar to the target alias.

   Matthias

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Richard Guenther]

On Wed, May 4, 2011 at 12:20 AM, Matthias Klose <doko@ubuntu.com> wrote:
> On 05/02/2011 09:53 PM, Diego Novillo wrote:
>>
>> Since google/gcc-4_6 follows the 4.6 branch, changes in minor
>> revisions cause unnecessary churn in directory names.
>>
>> Fixed with this.  OK for google/gcc-4_6?
>>
>>        Google ref 4335466.
>>
>>        * BASE-VER: Change to 4.6.x-google.
>>
>> diff --git a/gcc/BASE-VER b/gcc/BASE-VER
>> index 4110f74..33d4edd 100644
>> --- a/gcc/BASE-VER
>> +++ b/gcc/BASE-VER
>> @@ -1 +1 @@
>> -4.6.1-google
>> +4.6.x-google
>
> is this enough? the subminor version number is encoded in more places, e.g.
> C++ headers, Go libraries, jar files.  For the Debian/Ubuntu packaging I'm
> just using symlinks from 4.6.x to 4.6 to avoid this kind of dependency.  Now
> that the -V option isn't supported anymore, maybe this could be addressed
> with something like a new configure option --version-alias=<value>, similar
> to the target alias.

The SUSE packages introduce gcc/FULL-VER as copy of BASE-VER and
strip the patch-level version from BASE-VER.  Some (but not many)
makefiles need to be adjusted to use FULL-VER but then everything
else just falls out nicely (and you lose the ability to install 4.6.0 and
4.6.1 in parallel, of course).  For some weird marketing reasons we
also drop "prerelease" from the version string and drop the patch-level
version down to the last release.

Richard.

>  Matthias
>

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Diego Novillo]

On Tue, May 3, 2011 at 18:20, Matthias Klose <doko@ubuntu.com> wrote:
> On 05/02/2011 09:53 PM, Diego Novillo wrote:
>>
>> Since google/gcc-4_6 follows the 4.6 branch, changes in minor
>> revisions cause unnecessary churn in directory names.
>>
>> Fixed with this.  OK for google/gcc-4_6?
>>
>>        Google ref 4335466.
>>
>>        * BASE-VER: Change to 4.6.x-google.
>>
>> diff --git a/gcc/BASE-VER b/gcc/BASE-VER
>> index 4110f74..33d4edd 100644
>> --- a/gcc/BASE-VER
>> +++ b/gcc/BASE-VER
>> @@ -1 +1 @@
>> -4.6.1-google
>> +4.6.x-google
>
> is this enough? the subminor version number is encoded in more places, e.g.
> C++ headers, Go libraries, jar files.

It work here so far.  All the places where the version number is
encoded in ultimately get it from BASE-VER.  For us, the important
thing is to avoid the churn in installed directory names and such.
What the version string says is not as important.


Diego