[OE-core] gcc 4.6 recipes naming

[Khem Raj]

On Tue, Apr 19, 2011 at 8:01 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> Hi Khem,
>
> On Mon, 2011-04-18 at 12:18 -0700, Khem Raj wrote:
>> I have gcc 4.6 under progress here. As we know the current release is
>> 4.6.0. I have been calling the recipes
>> to omit the minor release number so the recipes are called
>> <recipes>_4.6.bb based on my experiences
>> with gcc releases over the years.
>>
>> Since the minor releases are bug fix releases and when next bug fix
>> release happens the total diff
>> of changes from 4.6.0 to 4.6.1 are also released as a single diff
>> which can be applied on top of existing
>> 4.6.0 tar file to reach 4.6.1
>>
>> This makes the upgrade easier for minor releases. I decided not to
>> track the release branch since
>> that complicates the gcc download as in classic oe
>>
>> So for upgrades we can either just take the diff from 4.6.0 to 4.6.1
>> and apply on top of 4.6.0 or
>> decide to use the new 4.6.1 tar both would be ok as we decide that later.
>
> I think this is just going to confuse people to be honest. I'm happy to
> stick to the 4.6.0 naming, then move to 4.6.1 and so forth over time.
> People expect to see the .X number else they just get confused about
> which patch revision we're at.
>
> What I'm thinking we will do differently to OE is not to have every
> point release available but try and stick to the latest. The exception
> would be when there is a problem in the point release version which we
> don't have a fix for.

usually later minor release will always be better (since they are bugfixes only)
so chances are less that we will regress

>
> Does that sound reasonable?
>

Yes having just one minor release at a time makes it easier certainly.
I was trying to make it easy to push updates and we could avoid some
git operations and logs would be straighter too since recipes would live
longer otherwise we will be git mv'ing them every 6 months when release happens.

If we need to reflect the minor number we could use PR fields too just a thought

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>