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 :/ Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
