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

Publish a release #49

Open
chriskilding opened this issue Jun 20, 2022 · 1 comment
Open

Publish a release #49

chriskilding opened this issue Jun 20, 2022 · 1 comment
Labels
question Further information is requested

Comments

@chriskilding
Copy link

At some point dev should be merged into master, and a release artifact of Ortho4XP should be published from master.

(This will have the side effect of making Ortho4XP/Ortho4XP the authoritative modern version of the code.)

Considerations:

What artifact format(s) to use?

This is complicated by the fact that Ortho4XP has both GUI and CLI front-ends. There's a decision there in its own right: should Ortho4XP continue to have both? Or should we settle on one or the other?

CLI app options:

  • APT / RPM / AUR... packages (Linux)
  • Homebrew formula (Mac)
  • Nuget/Winget/whatever it is nowadays installer (Windows)

GUI app options:

  • Flatpak (Linux)
  • .app (optionally in a .dmg) (Mac)
  • Windows app executable

How to publish it?

Manually? Or driven from Github Actions?

Where to publish it?

The easiest first step is to attach the release artifacts to the associated GitHub Release. This enables manual downloads.

Then comes

  • Homebrew cask installer (macOS GUI)
  • Homebrew installer (macOS CLI)
  • FlatHub (Linux GUI)
  • and so on
@girotobial girotobial added the question Further information is requested label Jun 21, 2022
@chriskilding
Copy link
Author

chriskilding commented Jun 24, 2022

It wouldn't be too much effort to put together a Homebrew formula that installs Ortho4XP as a CLI app, and stick it in a private brew tap. It could even install preferentially from the dev branch rather than master if we like.

Doing that would let us know how many native dependencies it has, and how gnarly it will be to set them up.

Would you like me go ahead and do that?

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

No branches or pull requests

2 participants