Support us on Patreon
PayPalGodot Engine 4.0 is so close now, with an overhauled and powerful Vulkan rendering system and now their developers have a new blog post up detailing some plans.
Right now they consider it "finally ready for production use" (but it's not out just yet) and they're keen to point out that "bugs and issues are inevitable" so regular bug fix releases will go up after. In the post from developer Clay John they point out that they do expect "users will encounter workflow-breaking bugs (especially on less common hardware), many workflows will feel unpolished, and performance won’t quite reach the goals we have set" which again follow-up releases will help clean up.
The good news is that for follow-up feature update release like 4.1, 4.2 and so on they plan to speed things up with quicker release cycles. For each big point release they will start merging new features, transition over to a period for just bug fixes, a release and then return back to merging in new features again. So they will get into a particular rhythm that should result in plenty of updates without such a long time in between.
For the first major point release in 4.1, they plan to focus on "stability, performance improvements, and usability".
When 4.0 does release, they say the Godot 3.5 "will remain the much more stable and battle-tested option" and they advise to continue using 3.5 until at least some of the 4.x releases.
So with the regular 4.0 Betas being released, they're getting it out the door when "it is ready to be used in production, not when it is perfect".
Article taken from GamingOnLinux.com.
Quoting: CatKillerRelease early, release often.I guess that's what they do, don't they. Anyone interested can easily get the latest bleeding edge version, and "the general public" doesn't have to live with latest bleeding edge bugs *unless* they explicitly opt in.
Quoting: CatKillerRelease early, release often.
I'm getting the impression developers don't update the framework for their Unity games, similar to device vendors who throw their thing over the wall.
If you can't expect frequent post-release engine updates, games in the wild using many different releases is not likely to work out well for maintenance.
Part of the solution is care for API guarantees and backwards-compatibility, but there's a cultural issue as well.
See more from me