Join GitHub today
Godot 3.0 entering release freeze (only major bug fixes accepted) #15321
Starting now, we're entering release freeze on the master branch to get ready for releasing Godot 3.0 stable in late January 2018.
This means that we will only consider major bug fixes from now on (crash fixes, fixes to very visible bugs that will impact the workflow of most users). Enhancements or non-critical bug fixes will no longer be merged in the master branch until 3.0 is released. Don't worry though, as we'll likely release a 3.0.1 maintenance version in February/March 2018 to bring more bug fixes and enhancements.
Translations strings are also frozen from now on, i.e. no
Why not branch off now?
An alternative workflow to freezing the master branch would be to branch off to a 3.0 stable branch, continue developing towards 3.1 in the master branch, and cherry-pick fixes to the 3.0 branch.
While this workflow works great for many projects, we prefer not to use it for Godot, as then most contributors would continue focusing on implementing features in the master branch instead of helping make the 3.0 branch stable. More than that, it means that PR reviewers (especially Juan and I) need to continue spending many hours reviewing 3.1 PRs instead of working on finishing 3.0.
The wait won't be long, and we ask that you all help us fix the remaining critical 3.0 issues ASAP: https://github.com/godotengine/godot/milestone/4 (this list will be greatly reduced in the coming hours as we will move non-critical issues to the 3.1 milestone).
My favorite PR or issue is still not merged/fixed, 3.0 will be a bad release :/
While you may be thinking that and this would be fully understandable, we ask you to contemplate the immense amount of work that has been done on Godot 3.0 since its development started in August 2016. Things have changed wildly over the last 18 months and it's more than time to get it out in the wild, even if things are not perfect yet.
There will be frequent 3.0.x releases to fix things, and we plan for 3.x releases (starting with 3.1) to have much shorter development cycle (to be determined, but likely 3-4 months each).
So yes, Godot 3.0 won't be perfect, and it might even have some issues that will be a hindrance to your workflow or game (for example performance issues on some hardware) - but we'll keep on improving it to keep establishing ourselves as a major player in the game development scene.
I'm not sure if this counts as major per se, but would there be a standard exporter from blender that exports best? I was running into issues with orienting bones but it would be nice to know how Godot fits into the open source workflow best.
I was using both the official gltf exporter but the kupoman one had more options for axis swapping which seemed to cause the bone issues.
There are 104 pages of issues. There are any system to categorize what are relevants or major bugs to stable release? Maybe some system to users to categorize priority of they bug reports can help?. For example: I have 11 issues opened (is real), but I think that 2 of them are totally relevant to master - stable release (real too), i categorize them and later developers choose what is more relevant between the previously categorized from users or something like this (or de-categorize if users are wrong).... I feel that are several "non stable-compatible" issues in this moment and i feel too that is too work to accomplish in one month, an several omissions can happend, and the unexpected regressions a.k.a retro-bugs... (probably i´m wrong, you are very committed developers). I trust in godot dev´s, but ¡¡¡2600 issues!!!......There will not be a release candidate cycle? Maybe one at least?
I will add to @akien-mga description of major bug fixes one that i considerate more relevant: bugs fixes that changes previous behaviours or make incompatibilities, there are most important to users (believe me like user that i´m), most that crash fixes (any program can crash, inkscape, gimp, blender.... sometimes crash) or performance problems...
I need to believe that godot dev´s have clear plan to stable release, because an stable version that is buggy-non stable is a pontential-exponential creator of hungry users, repeated issues, forum-battles, etc.... If this plan can be explained probably users can colaborate to accomplishment.
@reduz Yes, i want help. I can compile now master, test some of the most relevant issues (in my opinion of course) and tag or suggest tag at least.. I haven´t clear vision of godot internals to suggest solutions and I can not test linux and mac, only win 7 32 and 64. If it´s enough i could help.