You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should come up with a consistent way to determine whether the active CI release process is the newest "latest" release or not. Potential solutions may involve looking at the current release version wrt the git tags. There may be other metadata we can attach to our git repo; a "latest" tag is not really appropriate (tags are supposed to be immutable), but we could consider a "latest" branch that is always set to the latest release (at which point, we can get the canonical release version associated with that commit); or potentially some other mutable git data.
We could also consider using workflow_dispatch as a means to start the release procedure (as opposed to pushing to a release/v* branch); in this way, the release manager could set a flag as to whether the current release will become the new "latest" release or not. Structurally, this might be the "best" as it provides a more structured approach to releases. This could be combined with a safety check (one of the earlier suggestions) to double check and make sure both automated procedures and the release manager agree whether this release is "latest" or not.
The text was updated successfully, but these errors were encountered:
We cannot use a dist-tag of v0.33 for example, otherwise we get an error when publishing:
Run npm publish --tag v0.33 web/client-api/types/build/deephaven-jsapi-types-*.tgz
npm ERR! Tag name must not be a valid SemVer range: v0.33
npm ERR! A complete log of this run can be found in: /home/runner/.npm/_logs/2024-07-22T13_50_46_671Z-debug-0.log
This is mainly about our release procedure always labeling the active release as "latest".
#5591
#5572
deephaven/deephaven-server-docker#94
We should come up with a consistent way to determine whether the active CI release process is the newest "latest" release or not. Potential solutions may involve looking at the current release version wrt the git tags. There may be other metadata we can attach to our git repo; a "latest" tag is not really appropriate (tags are supposed to be immutable), but we could consider a "latest" branch that is always set to the latest release (at which point, we can get the canonical release version associated with that commit); or potentially some other mutable git data.
We could also consider using the Github release API as the canonical source, and use that to figure out what the latest release is: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#get-the-latest-release
We could also consider using workflow_dispatch as a means to start the release procedure (as opposed to pushing to a
release/v*
branch); in this way, the release manager could set a flag as to whether the current release will become the new "latest" release or not. Structurally, this might be the "best" as it provides a more structured approach to releases. This could be combined with a safety check (one of the earlier suggestions) to double check and make sure both automated procedures and the release manager agree whether this release is "latest" or not.The text was updated successfully, but these errors were encountered: