-
Notifications
You must be signed in to change notification settings - Fork 46
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
Conversation
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. |
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. |
Hmm, seems like the releases are not created? |
Ooh, nevermind. |
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 |
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.) |
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. |
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.) |
This automatically creates a release for each commit done on the
master
branchThis 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