More changes requested by FlatHub

[mcarans]

The FlatHub approval is proving to be a bit of a pain. I will need to have a tag once this is merged so I can update it in the Flatpak YAML in the PR on FlatHub. Given that making a new release involves changes in various places and I can't be sure that FlatHub won't come back with more changes, do you think making a GitHub tag such as 1.92.0.1 without a full release is ok? If they come back with more, I might need to make 1.92.0.2 etc.

[AnotherCommander]

It should be fine to tag various commits as 1.92.0.1, 1.92.0.2 etc. as long as no actual release is necessary. Keep in mind that the auto-build process tags commits to master with the build version anyways and those should probably be changed manually whenever you want to make flathub-specific tags. Can this be done? I do not know that but if it can be done no problem with the proposed plan.

[mcarans]

@AnotherCommander As this is on the 1.92-maintenance branch, if I understand correctly, I think that a release will not be created by the workflow: https://github.com/OoliteProject/oolite/blob/1.92-maintenance/.github/workflows/build-all.yaml#L358

As for the version used in the Flatpak for FlatHub, I have made it default to $VERSION here: https://github.com/mcarans/oolite/blob/b3598ea8c5295277277c1c0ad05343e9df2403ac/installers/flatpak/flatpak_postbuild.sh#L7 where VERSION=$(cat ../src/Cocoa/oolite-version.xcconfig | cut -d '=' -f 2) so it won't have Git revision, date etc. Only local and CI Flatpak builds by way of the create_flatpak.sh script will set VERSION_OVERRIDE such that it includes Git revision, date etc. using $VER.

Once you approve or merge this PR, I would then create a tag 1.92.0.1 in the branch. Is that ok?

[AnotherCommander]

Yes, it should be fine. Approved.