Shouldn't Master get all these changes first then we switch to stable
branch when we have a new release?

My German genes are raging about "Rules" ; )

- armin

On 04/06/2018 08:29 AM, Richard Purdie wrote:
> On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote:
>> A) Some layers only switch to an official branch name when the find a
>> reason to. E.g. branch "sumo" is created on openembedded-core but
>> meta-A keeps working on master unless an incompatible change is
>> created in openembedded-core that forces meta-A to create a "sumo"
>> branch.
>> B) Other layers create official branches the moment they exist. E.g.
>> branch "sumo" is created on openembedded-core and meta-B instantly
>> creates a "sumo" branch to mark this point in time, and continues
>> working on master. If meta-B's "sumo" branch fails to build against
>> openembedded-core's "sumo" branch because an incompatible change is
>> made to openembedded-core's sumo branch, meta-B fixes the issue on
>> the sumo branch.
>> I can see how the change you've implemented will be very useful for
>> the A)
>> cases. Will it be needed for the B) cases? In other words, does the
>> code
>> you're adding implicitly assume:
>>      LAYERSERIES_COMPAT_<...> = "layer"
>> for any given "layer"?
> No, there is no implicit assumption.
> In both A) and B) cases the maintainer adds the new "codename" to the
> list of compatible layer series in LAYERSERIES_COMPAT_<layer> for their
> layer. They can list multiple layers in there, e.g. "rocko sumo".
> The one annoying thing about all this is the layer maintainers do have
> to update layer.conf each time a new release codename comes out. I
> think that is a reasonable compromise to be able to give users a much
> better idea of which layers are compatible or incomaptible with their
> setup though. It means someone has looked at it and believes it will
> work with a given release series.
> Just to be clear, "layer" would never be a valid value there, it will
> always be the release/branch codenames.
> Cheers,
> Richard
> _______________________________________________
> Openembedded-architecture mailing list

Openembedded-core mailing list

Reply via email to