Hi,

I was wondering if there is any specific version/branch/commit of Kha/Kore that has been tested to work on all the platforms (at least G4)? Like if someone where to jump all-in on production of a game, how would they know what the safest version to settle on is? My initial thought was that the version shipping with Kode Studio is the one to use, but considering there hasn't been any commits to the Githhub repo since Nov '18, I'm wondering if that version is outdated (or if it's actually "perfect" and fully tested on all platforms)

My main concern is about console support as there is no way for me to test those backends.

Such a version does not exist and I don't even want it to exist. The standard workflow with Kha is to use it as a submodule in your project so you can test Kha and your project on all the platforms you care about yourself when you are nearing a release and can apply local fixes as needed. And about consoles - sorry but if you can't test console builds there's no way you can make a console release and that goes for any engine/framework/whatever.

I remember watching on youtube a talk you did a while back about Kha where you mentioned building an automated testing framework to verify that the various backends work/look the same. That's what I meant by a "production ready" version. Something like that would be awesome, and I'd be willing to help out if it'd help stabilize the Kha backends.

But if shipping a product with Kha means you need to get deeply involved with the codebase and fix bugs that are pretty much guaranteed to be there due to the fact that there's no stable branch, that's a hard sell IMO.

Some of that testing is in place nowadays (I recently got a new server and can finally do automated mobile builds). But you will still encounter bugs - and that's true for every non-trivial piece of software. Don't expect a unicorn.

One more to hopefully avoid any confusion: I'm very interested in improving stability and cross-platform feature-parity on every build, for example via automatic build testing like I mentioned in my talk. But I'm not interested in the classic process of stopping regular development for an undefined amount of time to supposedly stabilize builds because I don't think that actually works.