Make branch versioning include the patch version number

[Dragoncraft89]

It would be good to have, e.g. 3.2, 3.2.1 as seperate versions, because a game that builds upon this flatpak may not have made the jump from 3.2 to 3.2.1 yet when the BaseApp upgrades, leading to potential bugs.

For example, I've been trying to build a flatpak for Super Tux Party depending on this BaseApp. It crashed because I accidentally exported the game with 3.1, but the 3.1 BaseApp version is actually 3.1.2, which caused the godot-runner to crash on startup

[Calinou]

This makes sense, I'll ask on IRC whether I can create new branches on my own or not.

Also, I'll probably remove the branch/3.1 and branch/3.2 branches once this is done, as people should be pinning the patch version in their manifests as well. As far as I know, there are only two Flatpaks depending on this BaseApp, so this is probably safe to do.

[barthalion]

Yes, you can. There's no way to prevent it on GitHub even if we wanted. You'll also need admin help (so, me) if you also want to delete 3.1 and 3.2 from Flathub repo completely, please open a ticket for that so I don't forget.

[Calinou]

@barthalion Now that I think about it, we should keep branch/3.1 and branch/3.2 as the initial release of a minor version doesn't have a suffix (i.e. the first release is 3.2, not 3.2.0). This is the preferred versioning scheme according to upstream.

[Calinou]

According to @TingPing on IRC, it seems doing this isn't a good idea. Since we can't guarantee Godot patch releases are fully compatible with each other, we should make a reusable module file and deprecate the BaseApp entirely. Module files could sit in a Git repository that can be used as a submodule.

I'll leave this issue open in the meantime.

[Dragoncraft89]

@Calinou. I'm having a hard time figuring out what a module file is in this context.

Can different games still share the same Godot runtime?

[Calinou]

I'm having a hard time figuring out what a module file is in this context.

A "module file" is a Flatpak manifest you include from another manifest. This is typically done for libraries so you can copy their manifests in multiple apps to avoid doing manual work in every app. Flathub's shared-modules repository is an example of this pattern.

Can different games still share the same Godot runtime?

Yes, but they may require different patch versions as Godot patch releases aren't fully compatible with each other. (It may sometimes work, but not always.)

If we switch to module files, different games will no longer be able to share the same Godot runtime, but this is probably not a big issue since Godot export templates are relatively small (~3-4 times smaller than Electron). Either way, if we have a branch for every Godot patch version, the likelihood of two apps using the same Godot BaseApp version is quite low. We only have two public Flatpaks using the Godot BaseApp right now anyway 🙂

Therefore, we should avoid abusing the branch system for this purpose as it's typically meant to be used for minor (or even just major) versions of libraries required by applications.

[Dragoncraft89]

@Calinou Then what is the purpose of this base app if not sharing the engine between games? One could easily distribute the exported .pck and binary file and it would just work.

[Calinou]

@Dragoncraft89 While you could do that, it's generally recommended for Flatpaks to be building applications from source rather than downloading precompiled binaries (unless no source code is available).

[TingPing]

Baseapps are literally just sharing binaries. They are very effective for something like WebKit where each build is an hour long. Godot is both not helpful because it is much smaller and as this issue is about has multiple versions applications may want.

[Dragoncraft89]

@Calinou any updates on this?

Is there some repo already, so that I can help out?

[Calinou]

@Dragoncraft89 Not yet, sorry.