On Mon, Mar 04, 2019 at 04:21:48PM +0000, Richard Purdie wrote: > On Mon, 2019-03-04 at 11:14 -0500, Tom Rini wrote: > > On Mon, Mar 04, 2019 at 04:06:47PM +0000, Richard Purdie wrote: > > > You mean like the BB_MIN_VERSION variable: > > > > > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/sanity.conf#n6 > > > > > > ? > > > > > > :) > > > > > > The changes were intended to be backwards compatible hence it > > > wasn't > > > bumped. Clearly something isn't playing as intended... > > > > Yes, that. I think we haven't fully used that well historically > > since I can only ever recall *kaboom* when using too old of a bitbake > > rather than a nice sane error message. Looking at > > https://wiki.yoctoproject.org/wiki/Releases and then some quick git > > history, we also must have had that mechanism available when I last > > ran into something like that even for the fairly ancient jumping > > around I've had to do a time or three. > > That variable has been around for a long time. It does get incremented > when we do nasty things which we know break things. If something sneaks > in, its more problematic. We do try and avoid API breakage. > > > In fact, can we make BB_MIN_VERSION match the table found there? It > > doesn't look like we have resources / time to test things on both > > current and min versions, so we should I think have the min match > > what we say should be used. > > The problem is more "test what?" on the min version. In this case its > rm_work which triggers it, the bugs tend to be unusual corner cases > which our test matrix, vast as it is might not catch. Case in hand, we > don't test rm_work on the autobuilder. > > I'm torn on forcing people to update, I've had a lot of complaints > about being being forced when they didn't need to in the past. Its also > true that we're not as backwards compatible as we could be, i.e. using > a modern bitbake on old metadata isn't always guaranteed either due to > the same kinds of problems :(. > > By this line of argument, we'd bump the minor bitbake version for every > bug fix and force people to it, just to "protect" them from themselves > :/
So, what's worse, people hit a bug that's fixed in a newer version, or when people upgrade one set of branches they have to update another repository too? Honestly, I could see the "but why do I have to update bitbake too?" complaint being more reasonable back in the early days after we moved to proper layers. Now that it's not just oe-core/poky but also meta-openembedded and meta-$BSP and maybe 2-5 other layers you also need to bump from branch to branch, adding bitbake to that mix seems a lot less of a big deal. I thought about this and re-drafted something a few times now. I think perhaps a happy compromise would be to move the BB_MIN_VERSION check from a hard-failure to the same level of warning we do on SANITY_TESTED_DISTROS, and make it track the suggested version for a release. This will both help to catch bugs that have been fixed already but still let people that know what they want (or don't want) to do, do it. -- Tom
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
