Godot: Godot 3.0 entering release freeze (only major bug fixes accepted)

[akien-mga]

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 TTR() string should be added or modified until the release, so that translators can work towards 100% completion for 3.0.

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.

[akien-mga]

Note: Documentation PRs will still be accepted. Now that the repo is frozen for API changes, it's a great time to double efforts on the class reference to make it as complete as possible for 3.0 stable.

[jedStevens]

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.

[Ron5s]

I just want to say that this is an amazing accomplishment and I commend all the developers of Godot. The final release of Godot 3.0 will be amazing, but Im more excited about what the future holds for it. Thank you for all of your hard work.

[Ranoller]

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]

@Ranoller There will be an RC, and 3.0 will not be the most stable of releases, but it will improve over time. Subsequent 3.x releases will get gradually more stable, similar to how it happened in the 1.x and 2.x cycles.

[reduz]

@Ranoller Also, if you want to help tag the most serious issues, that would be welcome

[Ranoller]

@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.

[gattila]

Are the mono supported export templates will be available in the RC ?

[akien-mga]

Closing to decrease the 3.0 backlog ;)

[jonglae]

is this runs and exporting Android??