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

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

[Flanagan, Elizabeth]

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
e.g.
LAYERVERSION_intel_nuc
LAYERVERSION_xilinx_kc705

I'll be happy to do the above layers if folks approve of this
addition. Or, alternatively, if anyone has a better suggestion to be
able to identify breaking changes, I'm all ears.

-b

-- 
Elizabeth Flanagan
Yocto Project
Build and Release

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

[Otavio Salvador]

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

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Richard Purdie]

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

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

[Richard Purdie]

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