Allow both Blish HUD and modules to promote from preview to release versions.
dlamkins opened this issue · 0 comments
dlamkins commented
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.