On Tue, Feb 09, 2021 at 11:27:57PM +0100, Sylvain Beucler wrote: > - Godot tries to maintain compatibility but there's no hard guarantee, and > incompatibilities may reveal themselves late in a game run. So it would be > good to track what Godot version each game was meant for (precisely, like > 3.2.3). > Multiple Godot packages (godot3.2-runner, etc.) could be an option. I think that's a fairly common concern for development tool upstreams, but isn't always borne out in practice. Overly restrictive dependency versions like .lock files are just as much of a problem for packaging. The "target version" can probably just be inferred by timestamps. In fact having the tutorial uploaded to debian would be a great test case that can show up any medium-term compatibility issues that need rebuilds. The complexity increase of splitting into minor versions can always be done later if needed, usually driven by reverse dependencies not supporting overlapping releases. > - Godot may come with engine extensions (which should be compilable as > separate .so), GDNative (which are basically .so embedded in the .pck) and > Mono scripts (.NET C# modules). > > - Mono modules will need a Mono-enabled version of the godot3 package, and > may have incompatibilities of their own if the game is built before/after > Godot with a different Mono version (but to a lesser extent than having a > different Godot version entirely). Probably worth documenting that, perhaps in the wiki, as something like "Considerations for packaging Godot games"?
Attachment:
signature.asc
Description: PGP signature