gcc 4.6 recipes naming

gcc 4.6 recipes naming

[Khem Raj]

Hi

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.

Let me know your thoughts.

-Khem

Re: gcc 4.6 recipes naming

[Richard Purdie]

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.

Does that sound reasonable?

Cheers,

Richard

Re: gcc 4.6 recipes naming

[Khem Raj]

On Tue, Apr 19, 2011 at 8:01 AM, Richard Purdie
<richard.purdie@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: gcc 4.6 recipes naming

[Richard Purdie]

On Tue, 2011-04-19 at 10:33 -0700, Khem Raj wrote:
> On Tue, Apr 19, 2011 at 8:01 AM, Richard Purdie
> > 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

Agreed, I'm just being clear what the expectations are! :)

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

I think this is fine, we do this for the other recipes too.

Cheers,

Richard

Re: gcc 4.6 recipes naming

[Kamble, Nitin A]

Also if we keep the 4.6.x notation, it helps matching gcc -v with the gcc_4.6.x package installed on the target.

Thanks,
Nitin


> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Tuesday, April 19, 2011 3:38 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] gcc 4.6 recipes naming
> 
> On Tue, 2011-04-19 at 10:33 -0700, Khem Raj wrote:
> > On Tue, Apr 19, 2011 at 8:01 AM, Richard Purdie
> > > 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
> 
> Agreed, I'm just being clear what the expectations are! :)
> 
> > > 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.
> 
> I think this is fine, we do this for the other recipes too.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core