Re: [RFC] Utilizing LAYERVERSION_ to identify breaking changes to a layer

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2013-06-20 at 21:33 -0300, Otavio Salvador wrote:
> On Thu, Jun 20, 2013 at 7:56 PM, Flanagan, Elizabeth
> <elizabeth.flanagan@intel.com> wrote:
> > I know I've run into this issue and I'm going to bet that other folks
> > have as well.
> >
> > When running some sort of continuous integration system (in my case,
> > yocto-autobuilder), I need to build to at least two releases back. The
> > problem is, sometimes, local.conf and bblayers.conf requirements
> > change, for example, a layer needs a BBMASK for the prior release but
> > can't have it for the current one or a layer gets split so that I need
> > to add two directories to BBLAYERS as opposed to just the one that I
> > used a few commits back. I currently have no great way of figuring
> > that out and it has causes immense amounts of pain.
> 
> I am sorry but I didn't follow what it will help. Can you please
> provide an example?
> 
> I always thought the right way to handle it is to have a branch...

In the autobuilder there is information about what it builds, lets say
that it should build "core image-sato". Sometimes we do
add/remove/rename or otherwise change things (e.g. we might drop
meta-toolchain now the -c populate_sdk target works for images).

What is being proposed here is that we should start using the layer
version information to allow the autobuilder to have a better idea of
what to run when.

LAYERVERSION_core already exists for other reasons and this would seem a
logical extension to it. If we're worried about the major version
changes being a problem, we could use a MAJOR.minor type scheme which
would still give the autobuilder the information it needs.

The aitobuilder can then look at the version and run "bitbake
meta-toolchain" in one case but populate_sdk for later versions, or
whatever.

Cheers,

Richard