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

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

On Thu, 2013-06-20 at 15:56 -0700, Flanagan, Elizabeth 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'd like to propose extending LAYERVERSION (which is already utilized
> in oe-core as LAYERVERSION_core) out to other layers.
> 
> meta-angstrom LAYERVERSION_angstrom
> meta-baryon LAYERVERSION_baryon
> meta-beagleboard LAYERVERSION_beagleboard
> meta-browser LAYERVERSION_browser
> meta-fsl-arm LAYERVERSION_fsl-arm
> meta-fsl-ppc LAYERVERSION_fsl-ppc
> meta-guacamayo LAYERVERSION_guacamayo
> meta-intel LAYERVERSION_intel
> meta-minnow LAYERVERSION_minnow
> meta-ti LAYERVERSION_ti
> meta-xilinx LAYERVERSION_xilinx
> meta-yocto LAYERVERSION_yocto
> 
> For bsp layers with multiple machine layers, like meta-intel or
> meta-xilinx, I'd suggest something like:
>
> LAYERVERSION_layername_machinename

Can we match the name that is added to BBFILE_COLLECTIONS please? This
is then discoverable and matches existing data.

Cheers,

Richard