ci: deploy hotfixes as prerelease

[benelan]

Summary

Change the hotfix deployment CI to use pre-releases, e.g. 2.9.0-hotfix.0.

Why though?

The need to publish hotfixes as pre-releases is related to Calcite's continuous integration setup. Calcite uses Release Please, which requires a linear git history to properly handle versioning and changelog generation. Release Please finds the most recent GitHub release's tag and uses it to determine the version bump (major, minor, patch) and which commits to add to the changelog.

In Calcite's workflow, the commits on the hotfix branch are synced to main after a hotfix is released. If hotfixes are released as semver patch bumps, Release Please will ignore all the commits that happened before the hotfix landed on main, which will omit items from the changelog and potentially release as the wrong version.

For example, let's say a v2.8.0 latest release was deployed, a v2.8.1 hotfix was needed/deployed, and then a new latest release is ready to deploy. This is the state of the git history in the example:

  * 0757be0 (HEAD -> main) fix: number sanitization
  * 14e9a92 (tag: v2.8.1) chore: release hotfix v2.8.1
  * 04e2a2c fix: types related build error
  * 1eee108 fix: focus style
  * 4062654 feat: add component
  | * 5253edd (hotfix) chore: release hotfix v2.8.1
  | * 25dff34 fix: types related build error
  |/
  * 302c41b (tag: v2.8.0) chore: release latest v2.8.0
  * a502c34 ...

Git history generation script for example

mkdir hotfix-example
cd hotfix-example || return
git init --initial-branch main

# install to and release from main branch
echo "truncated" >one
git add --all
git commit --message "..."
echo "latest release" >two
git add --all
git commit --message "chore: release latest v2.8.0"
git tag -m v2.8.0 -a v2.8.0 HEAD
echo "feat" >three
git add --all
git commit --message "feat: add component"

# install to and release from hotfix branch
git checkout -b hotfix v2.8.0
echo "hotfix" >four
git add --all
git commit --message "fix: types related build error"
echo "hotfix release" >six
git add --all
git commit --message "chore: release hotfix v2.8.1"
git tag -m v2.8.1 -a v2.8.1 HEAD

# sync hotfix -> main
git checkout main
git cherry-pick ..hotfix
sleep 1 # fix timing issue

# GitHub's rebase merge option creates new commit SHAs, meaning the hotfix tag
# won't exist on main. Release Please will abort if it finds a GitHub release
# without a release tag on the branch its running on, so the tag needs to be
# recreated on main.
# https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github#rebasing-and-merging-your-commits
git tag -f -m v2.8.1 -a v2.8.1 HEAD

# install fix to main branch
echo "fix" >seven
git add --all
git commit --message "fix: number sanitization"

# visualize history
git log --all --decorate --oneline --graph

The upcoming latest release should be deployed as v2.9.0 and the changelog section should have entries for the commits that landed on main but not hotfix.

The changelog should look like this

## v2.9.0

### Fix

- fix: focus style
- fix: number sanitization

### Feature

- feat: add component

## v2.8.1

### Fix

- fix: types related build error

However, Release Please will stop looking at commits once it finds the most recent latest release tag, in this case the v2.8.1 hotfix. This means the release will be deployed as v2.8.2, since there is one "fix" commit since hotfix was synced to main.

The changelog will incorrectly look like this

## v2.8.2

### Fix

- fix: number sanitization

## v2.8.1

### Fix

- fix: types related build error

Calcite's solution to this issue is deploying hotfix v2.8.1-hotfix.0 instead of v2.8.1, v2.8.1-hotfix.1 instead of v2.8.2, etc., because GitHub Releases aren't created for pre-releases. This means Release Please will ignore their tags, so the version bump and changelog generation will be correct.

[jcfranco]

✨🦾🤖✨

[benelan]

Closing in favor of #9514