Continued support for 3.x?

[elvisish]

I've noticed that since 4.0 entered beta, there's been a greater amount of answers to problems with 3.x resolving with fixed in 4.0 or no plans for backporting to 3.x. For many years, when anyone asked if they should wait for 4.0 to be released or start working in 3.x, the answer was always to start now as there would be no guessing when 4.0 would be released, but now the inverse seems to be true... if something doesn't work in 3.x, we should be porting to 4.0. Having worked over the years with unstable, bleeding-edge software, I can safely say I would never trust production work in a tool that was still in beta, but right now 3.5 feels as though it's being dropped in favor of a much less stable option. Also, the fact that most addons haven't been ported to 4.0 yet and the API is still not 100% finalised, I think many people will still be relying on 3.x for a good few years until 4.0 is as stable and road-worn as 3.x.

This isn't to say the work on 4.0 isn't awesome and should definitely be where future development is focused on, I just wish there was a little bit more emphasis on what was the only version of Godot until a few months ago... hopefully still plenty of good innovations can be considered for backporting (if possible, and if there's anyone available to provide it).

[theraot]

There is still work being done on the 3.x branch. Even though most things are not back ported, some are (mainly the things are are easy to back-port). Furthermore, there probably will be a Godot 3.6. Regardless, afterwards 3.x will still get support. So even if it does not get new features anymore, it will still get fixes.

About using 4.0, it might help getting familiar with the changes, and also to spot and report bugs. Yet, using it production remains a risk. Nobody should push you do so. In fact, you might prefer to wait a few minor versions before fully migrating to Godot 4.

[awardell]

If there are specific bugs affecting you that you see resolved with fixed in 4.0 but not no plans for backporting to 3.x, then you should consider making a ticket specifically to request the back-port.

[elvisish]

Yeah, I’ve been doing this when something’s come up, but the answer I tend to get is “this is in 4.0” and the vibe is that I should be using 4.0 instead of 3.x. That’s mainly what I’m discussing, the immediate comparison to 4.0 makes it feel that I should be updating to a beta tool instead of using a stable one until at least 4.0 RC.

[oeleo1]

3.x is the thing to use for any serious project. 4.0 is (IMO) years away from anything which will reach production stage. This opinion is probably not shared by many in the current Godot community, but that's what you get with free software based on enthusiastic volunteers. People get more excited from working on new features (4.0) than from squashing bugs (3.x) which most engineers don't perceive as very rewarding.

Yet, a game is a product, and a product needs quality. Any serious project manager will turn a blind eye to Godot 4 for the foreseeble future, despite all the exciting stuff that is going on. The real stuff (if any) happens with 3.x.

That being said, we are quite happy with the support of 3.x and the backporting of a the few new features (which I am definitely not very excited about - be it particles or whatever shiny goddes-like functionality is in the works for 4.0). I track regularily the commits in the 3.x branch and kudos to the Community and especially @akien-mga for fine-selecting what can get backported and what not. I am particularly satisfied with the various platform (iOS/Android) bugfixes and evolutions.

Last but not least - making a good game is a hard undertaking. It does not depend on the engine or its version. If your game relies on the new features of Godot 4, I suggest you rethink your game concept again :-)

[elvisish]

For instance: godotengine/godot#54644

I don't have time to look into 3.x rendering issues, and interest in detail textures is relatively low among game developers nowadays. Therefore, this is something you'll have to look into fixing yourself.

This implies to me that 3.x rendering issues are no longer of any concern in favor of development on 4.0. As it happens, I found a workaround for this (shader) so it’s no longer an issue for me, but the implication is that 3.x is being actively depreciated?

[oeleo1]

No, 3.x is not deprecated. To the contrary it is being recommended as the main thing to use.

To your particular issue, from what I see there has been a lengthly exchange to clarify a very specific use case. We have experienced tons of those and went ahaid with workarounds. Godot is full of bugs, even in the maintenance branches, but where it shines is that none of this is a show stopper and you can move on with a workaround. If there is a serious show stopper, a bug is filed and fixed. Guess what -- in 4 years of using Godot, we haven't had a single case of a show stopper without a viable workaround. Not even when object memory management was a mess with functions like is_instance_valid(). So, relax :-) If you are on 3.x you are on the right track.

[YuriSizov]

We have limited resources, and at this point in time it is very important for us to finish Godot 4, and start to iterate on that. We are committed to releasing at least one more minor update to 3.x, which would include various improvements and features, including some backports. But we don't have enough people to maintain both branches with full attention. We are open to give community the means to continue the maintenance of the 3.x branch going forward, while the core team focuses on the most modern version.

We are also confident that users who need to release a game with Godot 3 will do so, even long past Godot 4 is out. People still work with Godot 2 to create their titles. And Godot 3 isn't going anywhere, it will continue to work as expected for as long as you can download and run it. But it cannot be developed forever. And not every fix can be backported to 3.x. We actually don't close important issues which still plague 3.x even after fixing them in the master branch. But that's when we know that the fix is feasible or that a lot of users have that issue and it's a major blocker. For the rest, yeah, fixing it in the next major version is the best that can be done and does resolve the problem in our mind. That's just the nature of things.

[oeleo1]

I fully second that opinion which is well understood. With the little added warning that unless 4.0 stabilizes enough to meet the requirement for production grade quality, the support for 3.x shall not drop below that requirement in order to avoid killing the existing user base.

[SysError99]

And Godot 3 isn't going anywhere, it will continue to work as expected for as long as you can download and run it.

Not true in certain platforms, especially Apple ecosystem and Google Play. They are well-known to break compatibility for applications with only 3 years old of lifespan. To be fair, there's nothing we can do about it but to keep upgrading the tool into recent compatible toolchains.

However I could agree that it's not extremely concerning because since Godot has full source code, and with enough effort, you still can recompile the tool and get the latest compatible binary on it, in exception that certain migrations require enormous efforts to get it backported, such as graphics.

[SysError99]

It's not extremely concerning especially if you only need stable environment and no new features (which is exactly what I want). It will get updated as long as there are people who want it and also people who can work with it. In contrast, Godot 2.x received around 3 years simply because it wasn't as popular as what 3.x is today and virtually none of serious projects shipped with Godot 2.x. It's not fair judgement to say that 3.x will be abandoned sooner or later especially when there are already many serious projects that need maintenance already shipped with 3.x, and 4.x still has significant number of bugs and imperfections that still make 4.x unfavourable such as currently broken HTML5 support, IK support, and legacy GPU support. Even then the lifespan of 2.x is still the same as major versions of Unity.

Ps., I still have GameMaker: Studio 1.4.9999 running til this day since HTML5 export is still working just fine, and Godot pretty much has more advantages on this since maintainers already planned to maintain support until virtually nobody in the community wants it.

[oeleo1]

Hear, hear... It's not extremely concerning since there are still a number of historical contributors who are devoted to dev and maintenance of the stable 3.x branch, whitness the very serious work @lawnjelly is doing currently on FTI for 2D, and I believe iOS/Android/HTML support will similarly not fade out any time soon. But the core team (on Godot's payroll or not) understandably cannot live any longer on support for 3.x, so 4.x is the natural next big thing to work on. However, as expected, although 4.x is already good to experiment with, it is still quite far from being mature enough for any serious project. What I find a bit irritating is that the official web site promotes its 4.x beta software in the first place, with the production grade LTS 3.5 being second in line, while it is clear that currently only 3.x is suitable for professional work. Any Godot insider or long timer will confirm this. But then again, the user poll explains it all - most Godot users are lone wolf enthusiasts so they naturally jump on the latest shiny thing of the day.

As of today it's a bit of a chicken and egg problem -- unless the 3.x serious projects matierialize enough to donate some funds for sustaining financially and enlarging the (pro) support of the the 3.x production base, it is expected that the 3.x support will be limited and will remain volunteer based. But it is far from being dead or underestimated.

[SysError99]

@oeleo1 Well you already foresee the problem. Godot really isn't a stability-focused project and only evolves even if they actually tried to make it as stable as possible. Plus, their major audiences are mostly indie devs, teachers, and kids that wanted to make games and immediately switch to other projects after they done with previous ones, and not actually teams or organisations that wanted a stable environment. So their main audiences actually don't see the evolution as a problem, or worse, they don't understand it as a problem. Maintainers basically pushed 4.x on schedule since less bugs are reported already and considerably ready to be published into next stable branch. While in fact it was 'only' stable because there aren't enough testers that actually test functionalities through entire project. First day of 4.x launch was a disaster and I already have seen many reports that 3.x projects break on 4.x because of their main audience's misunderstandings on how software development works. If you see it as a guinea pigs tactic, you're absolutely right. It's mostly how open-source community is doing things, and you are virtually a volunteered (late) beta tester on the project on very first launch of major versions. MIT licence was written for exact purpose, you can't sue them back if it breaks your property and you take full risk on your responsibility. However I do agree with you that pushing 4.x as pioneer was the worst decision/tactic ever because not everyone knows how software development works, and not everyone is actually ready to even take a position as late beta testers.

I personally hope that Godot 4.x would be the last version that got significant source rework and finally is able to follow what other game engines are doing, especially Unity. Unity is a great example of production tools done right. Every major versions they don't break things too often, and breaking changes weren't a lot. Still, that's just my opinion, and it all depends on the maintainer.

[oeleo1]

Godot really isn't a stability-focused project and only evolves even if they actually tried to make it as stable as possible.

I beg to differ. Godot 3.5.2 is pretty stable and rock solid. Not much to do beyond new features + the existing feature set is good enough for most use cases (2D, as far as we are concerned). There have been architectural discussions about 4.x's graphics design and future (Vulkan) and the limitations of the current 3.x approach, but beyond a few glitches here and there on 3.x, it's definitely not a problem currently. I have yet to see on 4.x something remotely competing with the 3.x GLES2 driver with batching, speedwise.

I think Godot 4 is a great project but it needs much more time to stabilise to the level of Godot 3. I don't see a problem with either of them, given their history. It's really a great OSS accomplishement and a breath of fresh air compared to Unity ;-)