[sorry this is long, I’m just throwing out my thoughts, and a reminder that mostly I’m no longer using this engine, but I try to support it as a community and continue to hope for a continued successful future - so don’t take my word for being worth anything]
Yeah I guess I’m just promoting or suggesting work toward an engine for the future, and not current, devices. Therefore a majority of the devices that support Vulkan/Metal will be a reasonably high percentage.
I’m also sort of assuming based on various comments and commits and repositories that have been worked on and created over the past few years that v4.x is going to ultimately be v3.x with some features removed that were not used very much and replace the rendering layer to better support the command-style rendering GPU APIs (Vulkan/Metal/DX12).
Therefore a v3.x game may not need any game-specific code changes, or hopefully at worst only small code changes, to support building the game using the v4.x engine.
In this way there would only be breaking changes at the rendering and shader layer. If a game has written custom OpenGL code, overridden onDraw (et al), or use custom shaders then there would be some amount of code changes or new code/shader to be written for those games.
Possibly also a removal of certain features if they’re not used much, at least from the default library. Maybe also a more componentized build source set up such that one could more easily add, but also disable, a component like Physics support.
Again, it’s also possible that the OpenGL rendering support could still exist in this incremental v4.x engine.
v3.x used when building for older Android devices that don’t support Vulkan.
v4.x used when building for iOS/Mac and those supporting Vulkan.
This is probably my mistake using the terminology “v4.x” for this basically same engine with a new rendering backend, and therefore you could decide to name it v3.20 or whatever and keep it as an incremental build focused only on adding support for Vulkan or Metal.
I think my idea is to maybe clean up some code allowing for some breaking changes, adding the new rendering backend, calling it v4.x and then work on an entirely new game engine (essentially) for v5.x with ECS or whatever other higher-level changes you want to make. Maybe that one is basically cocos-lite focused mostly on the CocosCreator/Javascript engine going into the future.
If instead you plan on v4.x to be a entirely new engine, such as using an entirely different architectures like ECS, or changing the way actions are applied, how memory is managed, how nodes are managed within a scene, etc, then my advice is probably invalid or incomplete.
In that case I guess it probably makes sense to write a Metal rendering backend for v3.x and postponing v4.x engine. My advice could still apply to this v4.x entirely new engine by looking into using an already written graphics rendering library/framework (e.g. BGFX).
(it really just depends on how much time your team plans to put toward the various components and features of each version and programming language)