blish-hud/Blish-HUD

Allow both Blish HUD and modules to promote from preview to release versions.

dlamkins opened this issue · 0 comments

Both Blish HUD and modules currently treat preview releases uniquely. A preview release is determined by different factors.

Blish HUD:

  • For updates: Release endpoint bool which indicates if the release is a prerelease.
  • At runtime: Indicated by the version number.

Modules:

  • For updates: Indicated by the packages manifest.
  • Modules do not act differently at runtime.

We'd like a way to promote both module and core prereleases to standard releases. This reduces update atrophy and gives time for AV to pick up a new release without disrupting thousands of users at once.

Changes needed for Blish HUD:

  • Blish HUD needs an external method of detecting release vs. prerelease.
    • We can't embed this fact with the release because the release artifact must remain the same before and after promotion to assist with AV approvals.
  • Identify all runtime behaviors that are unique in prerelease builds vs. standard builds and ensure they are accounted for.
    • This is especially important for anything needed at startup as an external request to an API will delay startup.
  • Update SSRD to support promoting a prerelease. We currently support prerelease deployments in SSRD, but with a minimal interface and no management options.

Changes needed for modules:

  • SSRD needs the option to promote a release.
    • Both repos need updated to remove the prerelease from one and add it as a release to the other.
    • Both pkgs manifests need to be updated once done with the changes in repo (these actions will likely auto-merge).
    • We should consider allowing auto-triggering and auto-merging promotions if certain criteria is met (x number of downloads, error/fatal threshold not exceeded, etc.) as an option.