Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically create releases #81

Merged
merged 3 commits into from
May 30, 2024
Merged

Automatically create releases #81

merged 3 commits into from
May 30, 2024

Conversation

Miepee
Copy link
Contributor

@Miepee Miepee commented May 30, 2024

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.

grafik

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
Copy link
Contributor Author

Miepee commented May 30, 2024

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
Copy link
Owner

Alcaro commented May 30, 2024

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.

@Alcaro Alcaro merged commit 46de6a2 into Alcaro:master May 30, 2024
6 checks passed
@Miepee
Copy link
Contributor Author

Miepee commented May 30, 2024

Hmm, seems like the releases are not created?

@Miepee
Copy link
Contributor Author

Miepee commented May 30, 2024

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
Copy link
Contributor Author

Miepee commented May 30, 2024

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
Copy link
Owner

Alcaro commented May 30, 2024

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
Copy link
Contributor Author

Miepee commented May 30, 2024

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
Copy link
Owner

Alcaro commented May 30, 2024

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automate builds for Windows and Mac and utilize github release system
2 participants