Re: Sample Godot game packaging (upstream feedback)

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"?

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYC6+JwAKCRDbymUJHySO
bEZfAQDXX+8AZNsaUKpQUUz/TaKbeKM9gIc22vtByYoLQKywFgEAj9neqXP+tjIu
WuzvEBWkIgTL3h28dexuuB956MXVoAM=
=/sPl
-----END PGP SIGNATURE-----