release candidate process for before full-release

[catilac]

This is adding a release candidate workflow.

It uses the tag workflow previously established. But now there is a branching path if the tag has a -rc<N> suffix. On this path it will not notify anyone, but will create a public downloadable pre-release we can iterate on.

Once we're ready we can just put the normal tag without the -rc<N> suffix and it will publish to gradle, maven, flathub, snap etc. And then we can update the website too.

[neobrain]

Confirmed building fine again without the two extra patches in nixpgs :)

[catilac]

Yay, thanks @neobrain !

[SableRaf]

@catilac Are you also planning a beta release flow?

We have support for side-by-side beta releases on the download page (screenshot below). There's a small but non-zero percentage of ppl who download the beta from the website, which increases the chance of catching bugs before they go to stable.

Snap also supports beta releases (people can chose to auto-update to the beta releases, which means more testers on Linux).

[catilac]

Ahhh. Yes. We'll need a follow up PR. I think that the beta should be whichever latest release candidate. What do you think @SableRaf ?

[catilac]

I think the RC and Beta are synonymous. This set up is so we are able to catch bugs in beta (or release candidacy) fix them and keep testing without leaving beta

[SableRaf]

The rc/beta distinction might be helpful. I'm not totally sure.

We did not use -beta or -rc suffixes in the past. @Stefterv had a good reason for it but I can't remember anymore. I think it might be relevant to this decision.

Note: the (still in drafts hell) updated Download flow is intended to allow more granular display of releases candidates, nightly builds, etc.