Let's support one version of Python and validate it

[SqAtx]

We're all aware that we're quite understaffed here at the moment, so I propose a change to simplify things a bit.

Let's declare that the only supported way to distribute GTG is via flatpak, and that the only version of Python that GTG is expected to run on, is "whatever version of Python runs in the latest version of the GNOME SDK flatpak runtime".

Currently,

• the README says that GTG requires Python >= 3.8
  • that's part of the larger problem of the README having outdated information about dependencies , which is already filed at Update dependencies in README.md #1001
• the unit tests GHA workflow uses Python 3.9
• GTG doesn't run on Python 3.9 - I think it currently requires at least 3.10 to start
• After we merge Bump runtime to 47 #1163 (and fix Weekly flatpak GHA is now failing #1184), we'll be building the weekly flatpak on GNOME 47, which uses Python 3.12

So I propose to declare that we're supporting only Python 3.12, and:

• say so in the README
• set it as the Python version in the unit tests GHA
• add a GHA test that tries to start GTG on every commit
• ideally, add an automated way to validate the weekly flatpak

This would both set expectations on the versions of Python that are supported, and validate that it actually is supported and that we're not breaking it by accident.

Of course, this strategy makes it more difficult to package GTG in different ways, but I don't think we have enough people interested in doing that currently. When we do, we can widen support, and we'll be able to test accordingly :)

[gycsaba96]

This is a great summary of the situation, and I fully support the proposal. It would allow us to concentrate our efforts and simplify testing.

However, I suggest a less strict "whatever version of Python running in the GNOME SDK used by GTG" specification to provide flexibility when transitioning to a new SDK.

[SqAtx]

However, I suggest a less strict "whatever version of Python running in the GNOME SDK used by GTG" specification to provide flexibility when transitioning to a new SDK.

Good point - we might need to test on two different versions of Python if an SDK upgrade drags out. That should be easy to do.