<div dir="ltr">FWIW: I've updated some layers with this <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">LAYERSERIES_COMPAT_<layer> today and I think it's good idea.</span><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">It probably won't be enough to stop questions like this:</span></div><div><span style="text-align:start;text-indent:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="font-size:12.8px"><a href="http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149696.html">http://lists.openembedded.org/pipermail/openembedded-core/2018-April/149696.html</a></span><br></span></div><div><span style="text-align:start;text-indent:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="font-size:12.8px"><br></span></span></div><div><span style="text-align:start;text-indent:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="font-size:12.8px">but it's still better to show warning first and then some often harder-to-read exception or error log.</span></span></div><div><br></div><div>Updating layer.conf in meta-qt5 was a bit more tricky as people tend to mix the meta-qt5 branches with different branches of other layers, just because their requirements for Qt are often very different than for other layers (e.g. many people still using meta-qt5/krogoth with Qt 5.6 because of the license, even with much newer morty, pyro, rocko, sumo, master branches of other layers and vice versa that someone is stuck with krogoth release for whatever reason, but needs newer LTS Qt 5.9 from meta-qt5/rocko). So for meta-qt5 I've used multiple values for <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">LAYERSERIES_COMPAT_<layer> for combinations I use somewhere (so that I cover at least some testing with such uncommon combination) and I'm willing to accept more values to it if someone really uses another combination regularly. The rest of combination (like meta-qt5/krogoth with dizzy, which is usable as described in meta-qt5 commits which introduced incompatiblitites, will eventually trigger the warning which is fine, because people should be aware that they are doing something less tested and that they might to implement some work arounds to make it usable).</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Regards,</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 5:29 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote:<br>
> A) Some layers only switch to an official branch name when the find a<br>
> reason to. E.g. branch "sumo" is created on openembedded-core but<br>
> meta-A keeps working on master unless an incompatible change is<br>
> created in openembedded-core that forces meta-A to create a "sumo"<br>
> branch.<br>
><br>
> B) Other layers create official branches the moment they exist. E.g.<br>
> branch "sumo" is created on openembedded-core and meta-B instantly<br>
> creates a "sumo" branch to mark this point in time, and continues<br>
> working on master. If meta-B's "sumo" branch fails to build against<br>
> openembedded-core's "sumo" branch because an incompatible change is<br>
> made to openembedded-core's sumo branch, meta-B fixes the issue on<br>
> the sumo branch.<br>
><br>
><br>
> I can see how the change you've implemented will be very useful for<br>
> the A)<br>
> cases. Will it be needed for the B) cases? In other words, does the<br>
> code<br>
> you're adding implicitly assume:<br>
><br>
> LAYERSERIES_COMPAT_<...> = "layer"<br>
><br>
> for any given "layer"?<br>
<br>
</span>No, there is no implicit assumption.<br>
<br>
In both A) and B) cases the maintainer adds the new "codename" to the<br>
list of compatible layer series in LAYERSERIES_COMPAT_<layer> for their<br>
layer. They can list multiple layers in there, e.g. "rocko sumo".<br>
<br>
The one annoying thing about all this is the layer maintainers do have<br>
to update layer.conf each time a new release codename comes out. I<br>
think that is a reasonable compromise to be able to give users a much<br>
better idea of which layers are compatible or incomaptible with their<br>
setup though. It means someone has looked at it and believes it will<br>
work with a given release series.<br>
<br>
Just to be clear, "layer" would never be a valid value there, it will<br>
always be the release/branch codenames.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
Openembedded-architecture mailing list<br>
<a href="mailto:Openembedded-architecture@lists.openembedded.org">Openembedded-architecture@<wbr>lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>architecture</a><br>
</div></div></blockquote></div><br></div>