The comes a time in every project where you have to switch from a developmental Work In Progress branch to the main branch and that time just occurred for the Godot game engine. The WIP Vulkan (and C++14) port is now the official branch on the Godot Github.<\/p>\n
Details from the Godot news page<\/a>:<\/p>\n The Vulkan port is not ready yet, but we need to get it merged into the We plan to rework a lot of Godot’s internals ( The scope of the planned changes means that it would be impossible to do these changes in the Up until now, we’ve been very cautious with regard to what changes we allow in the So we need everything in the main branch to stop limiting ourselves.<\/p>\n<\/blockquote>\n Moving the development branch from 3.2 to 4.0 has some side effects, specifically outstanding Pull Requests. Unfortunately the simplest option seems to be the best in this case, to close those requests and hopefully \u201cport\u201d them to the new master branch.<\/p>\n While closing PRs may seem a bit abrupt, we ask all contributors to understand that this is done to help us cope with the sheer amount of proposals in parallel to having to refactor a lot of the engine’s codebase. This closing does not mean that we reject<\/em> the PRs, nor that we do not seem them as worthy contributions. But by asking the authors to re-assess their own proposals and make them compatible with Godot 4.0, we will save a lot of precious development time and get ourselves some breathing air in the current overcrowded PRs.<\/p>\n Closed PRs will have the If you use a major release version downloaded from Godot\u2019s download page or from Steam, this change doesn\u2019t actually effect you. If you want to check out the new Vulkan master branch but don\u2019t want to build the code yourself, you can get a nightly build here<\/a>.<\/p>\n Learn more about this change and it\u2019s ramifications in the video<\/a> below.<\/p>\n [youtube https:\/\/www.youtube.com\/watch?v=7kpSUd-8zHs&w=853&h=480] <\/p>\n\n
master<\/code> branch as a lot of further development planned for Godot 4.0 depends on it.<\/p>\ncore<\/code>) to allow fixing long-standing design issues and improving performance (including GDScript performance improvements). Moreover, our long-awaited port to C++14 will also happen now that the vulkan<\/code> branch is merged into master<\/code>, and many other codebase-wide changes were waiting for this: code style changes, Display\/OS split, renaming of 3D nodes to unify our conventions, etc.<\/p>\nmaster<\/code> branch while keeping the vulkan<\/code> branch separate, just as it would not be possible to do all those changes in the vulkan<\/code> branch itself before merging into master<\/code>: any rebase\/merge would become extremely difficult due to the sheer amount of lines of code that will change.<\/p>\nvulkan<\/code> branch, as well as what new PRs we merge in master<\/code>, to ensure that the vulkan<\/code> branch can always be rebased on top of master<\/code> for a later merge. I’ve been rebasing it periodically over the past 8 months, and even though we’ve been very conservative in the scope of the changes, in later months a full rebase could easily take me a full day of work.<\/p>\n\n
salvageable<\/code> label, which we use to denote PRs with code that could be salvaged to make a new, updated (and possibly improved) PR, either by the original author or by a new contributor. So we will not lose code in the process, since everything will still be accessible from the closed PRs and easily identifiable thanks to the salvageable<\/code> label.<\/p>\n<\/blockquote>\n