Integration options with new CI build

[joshuaboniface]

Reviewing this as part of the larger CI project.

Ideally, Windows installers will be built automatically for new releases (starting with 10.9.0).

The CI in this repo seems sufficient to do so. The main question will be how to call it. I see 3 options:

1. Keep this repo entirely the same. Trigger a tag and, if needed(?), release build, manually from the main CI once the Windows installer completes.

This is a viable option but I'm not the biggest fan of the cross-repo dependency and full reliance on GitHubisms, if it even is possible (I've had a few people say it is but how to actually do this I'm not sure yet).

2. Ditch the idea of tagging this repo, use it as a submodule in packaging repo, call the CI directly from there.

I like this option a bit more, as then it could, in theory, all be run by a local runner or something. There would be no more tagged releases here though, unless they're added later by the process (maybe that's viable too?).

3. Move the CI entirely out of this repo and into the packaging repo, call CI as if it was a 3rd component.

I like this option the most, if only because then all the server CI is in one place. No tagging here at all really again unless really desired, the CI just exists in packaging, and a submodule provides the code for the CI to build.

So, putting it to the rest of the maintainers - which would you prefer.

[anthonylavado]

Well as the maintainer is largely me, it's whatever you prefer. To keep with tradition, I'd like to have the release tag etc cut here as it has been done. I will defer to your preference though.

[anthonylavado]

@joshuaboniface Feel free to link the workflow into the release process.

The current steps:

• create a tag with the new version number
• It downloads the prepared windows package with that number
• it builds the tray app
• it builds the installer

We should add a step where it uploads to the download repo as well.