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

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

Open
4 tasks
dlamkins opened this issue Apr 13, 2023 · 0 comments
Open
4 tasks
Labels
feature New feature or request

Comments

@dlamkins
Copy link
Member

dlamkins commented Apr 13, 2023

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.
@dlamkins dlamkins added the feature New feature or request label Apr 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant