Skip to content

Latest commit

 

History

History
25 lines (20 loc) · 1.65 KB

RELEASE.md

File metadata and controls

25 lines (20 loc) · 1.65 KB

Release

This is a dstack release guide and checklist for core maintainers.

Checklist

  1. Test master:
    1. Compare changes to the previous release, e.g. https://github.com/dstackai/dstack/compare/0.19.39...master.
    2. Test that master CLI works with the previous server release. PRs that add new model fields can potentially break client backward compatibility.
    3. Test that master server works with the previous CLI release.
    4. Pay special attention to releases with DB migrations. See MIGRATIONS.md.
    • Ensure migrations work with rolling deployments and do not lock multiple tables.
    • Test applying migrations while old replicas do active processing.
    • Test migrations can be retried if they fail. For example, concurrent index may fail and stay in invalid state.
  2. Create a tag, e.g. git tag 0.19.40.
  3. Push the tag to trigger the Release workflow, i.e. git push --tags.
  4. Generate GitHub release notes from the tag. Highlight major features, deprecations, breaking changes.
  5. Install the release build and test once again, e.g. uv pip install 'dstack[all]==0.19.40' --refresh.
  6. Release dstack Sky and dstack Enterprise.
  7. Publish the release notes and make announcements.

Troubleshooting

  • If a release workflow fails due to a release workflow mistake and the release build is not published, commit a fix and update the tag reference: git tag -d 0.19.40 && git tag 0.19.40 && git push --tags -f.
  • If a critical bug is found after the release is published, make a new release. In an extreme case, the broken release can be yanked.