Automatically create releases

[Miepee]

This automatically creates a release for each commit done on the master branch

This runs after the optimized builds for win/lin/mac have been created.

The tag and release title is v{AMOUNT-OF-COMMITS}
The body just lists the commit.

This should work ootb for you with no need to do any repo configuration.

If you want a different release title/body, lemme know, I'm very uncreative in regards to that.

Fixes #56

[Miepee]

Hmm, I realized that apparently some versions already exist (1.31). So will leave to you how you'd like future releases getting tagged moving forward.

[Alcaro]

On one hand, the commit message would be a sensible release body ...but on the other, automatically making a release for every commit is pretty far from sensible already, so a more mechanical-looking body helps call attention to the automated nature of such releases. Fair chance half of the resulting releases would just be 'Merge branch octocat/fix-readme-typo into master', anyways.

Commit count is a fine version number, the readme already suggests that ("There will be no formal releases within any forseeable future; every commit should be considered a release. If you need a version number, use the commit count."). The old releases are from when Flips was actively developed, when I was more enthusiastic and less jaded. Changing the release naming style is fine.

However, I will make two small changes. First, now that there are releases, the readme will be updated. Second, I will not make releases containing binaries for platforms I can't test bug reports for, or otherwise support.

[Miepee]

Hmm, seems like the releases are not created?

[Miepee]

Ooh, nevermind.
They can be found at https://github.com/Alcaro/Flips/releases , but my browser just didnt seem to update the cache of the main page to link to that

[Miepee]

Second, I will not make releases containing binaries for platforms I can't test bug reports for, or otherwise support.

My two cents: This project is in maintainability mode; so support is basically non-existant anyway, and bug reports have a higher chance than usual of not getting fixed. So might as well at least expose that macos builds exist, especially so people in the romhacking scene have an easier time pointing to patcher software (i.e. "download flips" instead of "download flips if on windows and linux, find something else for macos"). Could potentially have The macos build is not supported and are only provided for experimentation in the release body to make it clearer if you want to 100% ignore every macos issue.

[Alcaro]

Yes, making the mac binaries more discoverable would improve the experience for people answering questions in the romhacking scene.

But I'd expect the end user experience to be worse. The binaries need some libraries most people don't have (GTK), don't integrate well with the OS (GTK limitations, iirc the Claim File Associations button is so Linux-only I had to disable it in flatpak, and I probably hardcoded some more linuxisms), and are not a well-behaved mac app at all (no Apple Gatekeeper signature, and most mac programs are distributed as some folder named .app or some archive format named .dmg). I think the mac folks would have a better experience using something else (MultiPatch, probably).

(Or if the romhack answer folks are lazy, they can just point to a Flips Windows binary and tell mac/linux users to use wine. That way, the mac folks will keep their expectations low enough that Flips satisfies them.)

[Miepee]

Hmmm, I see.

FWIW, I think some macos' users expectations are really low already, considering how much software already doesnt/barely work(s). Even freaking minecraft isn't properly signed so users get the gatekeep prompt there (could have been fixed by now tho, who knows).

But if you think that the current way is better, I'm not gonna be pushing against that.

[Alcaro]

The best solution here is making a mac-native GUI, and teaching the CI about all the signatures and whatever.

I agree that all other solutions are bad, but until and unless someone puts in that effort, we'll just have to pick the least bad solution.

And since neither of us are familiar with macs or mac user expectations, we can't know for sure which option is worse. I could be wrong, you could be right; until we know, we should pick the less risky option. Sure, it reduces the potential user count, but I'd rather prioritize average user satisfaction over user count. (And if you really need a mac flips, you can grab binaries from the Actions tab.)