• poVoq
    link
    fedilink
    -610 months ago

    That someone felt the need to make such a tool is a seriously bad sign about version compatibility in Godot.

    • @popcar2
      link
      English
      1210 months ago

      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.

      • poVoq
        link
        fedilink
        510 months ago

        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.

        • @popcar2
          link
          8
          edit-2
          10 months ago

          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.

          • poVoq
            link
            fedilink
            410 months ago

            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.

            • @[email protected]
              link
              fedilink
              210 months ago

              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:

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

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

        • @[email protected]
          link
          fedilink
          110 months ago

          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.

      • poVoq
        link
        fedilink
        -410 months ago

        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.

          • poVoq
            link
            fedilink
            310 months ago

            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.

            • AtegonMA
              link
              English
              510 months ago
              • Testing pre release versions
              • Editor version to match the game for game mods
              • Godot 3 vs Godot 4
              • GdScript vs C#
              • poVoq
                link
                fedilink
                210 months ago

                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.

                • AtegonMA
                  link
                  English
                  3
                  edit-2
                  10 months ago

                  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

                • @[email protected]
                  link
                  fedilink
                  English
                  2
                  edit-2
                  10 months ago

                  Point 3 are completely different engines and it is very unlikely that you need to switch between them regularly

                  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.

    • Rho
      link
      410 months ago

      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

      • @[email protected]
        link
        fedilink
        110 months ago

        It really depends. If your game is released to the public in like early access or such then not upgrading might be ideal.

        • Rho
          link
          110 months ago

          you will likely keep updating the game, adding content and fixing bugs

          • @[email protected]
            link
            fedilink
            210 months ago

            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.

    • @[email protected]
      link
      fedilink
      210 months ago

      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.

      • poVoq
        link
        fedilink
        210 months ago

        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.

    • Gamma
      link
      fedilink
      210 months ago

      I’ve been using one of the other version managers for godot for a little over a year, no need to be so dramatic