Nice app I saw shared
Source: https://github.com/MakovWait/godots
Download Links (Win, Macos, Linux): https://github.com/MakovWait/godots/releases/tag/v1.0.stable
Nice app I saw shared
Source: https://github.com/MakovWait/godots
Download Links (Win, Macos, Linux): https://github.com/MakovWait/godots/releases/tag/v1.0.stable
That someone felt the need to make such a tool is a seriously bad sign about version compatibility in Godot.
Godot 4 is a major overhaul of the engine, it’s not meant to be compatible with 3.x projects. Godot 4 is stable and won’t change any time soon.
Godot 3.x and 4.x are major release versions that break API compatibility. It is very unlikely that you are developing a game for both versions the same time, so no need for a tool to switch easily between them.
I am not talking about general stability, but API stability. Normally you want a game project to work with any version of the Godot 4.x release cycle.
Godot 4.x projects are compatible with each other and are stable but some people don’t upgrade right away for stability or plugins specific to that version. You don’t see many companies upgrading from Unity 2021 straight into Unity 2022 when it drops, they’d still use Unity 2021 for various reasons. That’s why Unity has Unity Hub for managing versions. I think a project like this can be useful.
Those major Unity release versions are more comparable to Godot 3.x and 4.x
My point is that evidently minor releases of Godot are not sufficiently API stable, so that people feel the need to create and use a tool to switch between minor versions to work around compatibility issues. And I have seen some people complain about exactly that with Godot.
This has been a problem since forever with Godot. They like to backport major new features from the development branch to a new minor version of the previous branch. This means the API in the previous branch (3.x right now) is supposedly stable in that it is only extended and not modified. However there are two problems with this:
If you use the new extended API is makes the project bound to that version and you lost backward compatibility. So it becomes the responsibility of the user to keep track of which feature are available in which versions and be conscious of backwards compatibility, instead of just sticking with a major version like you can with basically every other software in existence.
It’s not even true. They modify the existing API and break projects all the time. The movement functions of the kinematic body classes have been changed at least three times during the 3.x cycle.
So you’re right, the API is not stable, but you won’t get far with criticism from a professional software standpoint in the community (have a look at the demographics listed in the recent community poll for some insight as to why).
Ultimately because of the relative instability of the API, I think this tool will be useful.
@popcar2 @poVoq there’s this guy who’s creating something similar: https://eumario.itch.io/godot-manager
I have a released game in 3.5. It is not realistic for me to update it to 4.0.
I have to keep that code in 3.5, but if I want to start a new project in 4 I need to keep both versions on my pc. This is why the tool would be helpful. So I can easily switch between the 2 versions.
How so?
You don’t need such a tool to manage version if the engine has a stable api on major versions. And you certainly don’t want to jiggle with multiple versions when developing a game, or be stuck on a specific minor version because the engine broke API compatibility outside of major versions.
It IS stable… this manager is just for convenience.
Convenience for what? If you have a stable API you just always use the latest stable version of the major release version you are targeting.
Point 1 & 2 shouldn’t need a version manager if the engine has a stable API.
Point 3 are completely different engines and it is very unlikely that you need to switch between them regularly, and point 4 is similar, but I concede that for that a version switcher might be somewhat useful.
Version manager for pre releases since you probably don’t want your main game on a pre release version but you can have a test project to test that version
Having same editor version for mods so things like bugs are the same
And when collaborating with others as well normally you stick to a certain version so you can do that while maybe doing latest version for a personal project
That’s not been my experience at all. I have multiple projects, more than half of them in Godot 3, but most of the new ones I create are in Godot 4. I often have to switch between the two versions to work on different projects. Even more switching is needed when porting a project from 3 to 4, where you regularly want to compare the two versions to check for regressions or to understand some code that was messed up by the automatic converter. That’s one of the reasons I use a project manager like Hourglass (aside: for those interested in hourglass, I have to inform you the version on the official website isn’t currently working, but I have submitted some MR/PRs to fix the issues, so you’ll have to wait if you want to use it. we are currently porting it to godot 4: https://gitlab.com/jwestman/hourglass/-/merge_requests/52).
I don’t disagree that there are often incompatibilities between versions, but they haven’t bothered me much (besides the obvious g3 vs g4). When something breaks on version switch, there are times where you want to withhold changing versions (due to a problem with the engine, or because the user was exploiting a behaviour of the engine that was not desired when originally involved parts were designed, for example), but in the cases where that is not the case (ie. most of the times) the problems are easily fixed (in my personal experience), but I think the changes generally are an improvement, so I think custom project managers are worth it and we can live well in the current state of things.
Edit: A point that I noticed wasn’t mentioned that I consider significant is that another situation a human may need to juggle versions is when that human has their own custom build of godot (or even multiple of them). A project manager allows to easily manage those different versions. There is a bigger need for version management in this case because unlike official releases one version isn’t “inferior” or “superior” to another and one generally really doesn’t want to change all projects to use those custom versions.
And that’s generally what we do.
if your game is in production you risk introducing bugs with every update, but you will probably want the latest version of the engine for your new game
It really depends. If your game is released to the public in like early access or such then not upgrading might be ideal.
you will likely keep updating the game, adding content and fixing bugs
Sure but that doesn’t mean you really want to do an engine upgrade. I know a few games that aren’t going to move to Unreal 5 since they were released into early access.
It’s not. Most game engine launchers have this versioning. It’s very understandable. You don’t want to open a project with 5.2 of unreal if it’s in 5.1 and the rest of your team is on 5.1. Your team won’t be able to load assets you’ve committed. Same thing is useful for Godot. You want to keep your engine versions synced with the team and minor versions simply just mean there shouldn’t be a painful upgrade. With unreal sometimes even minor versions have large API charges. In that regard Godot is very stable.
So your only argument is: it’s bad on Unreal as well?
One of the reasons why there is so much never updated shovelware in the gaming market is because many game engines do not follow software industry best practice of having a stable user-space API for minor versions.
I’ve been using one of the other version managers for godot for a little over a year, no need to be so dramatic