release: v0.14-alpha.1

[mmagician]

Release plan summary:

0. Here are the changes in this branch relative to next
1. Merge this PR to main. After the merge, main will be on version v.14.0-alpha.1
2. After merge: create a GitHub Release with tag v0.14.0-alpha.1 targeting main, like so:

3. This will trigger publishing to crates.io

For patch releases

1. Since main is about to move to alpha, I created a new release/0.13 branch off current main to preserve v0.13.x for hotfixes
2. I also created a new branch protection rule mirroring the one for main
3. CI updates: the publish and dry-run workflows were hardcoded to main. Updated them to use github.event.release.target_commitish so releases can be published from any branch (e.g., release/0.13 for hotfixes, main for new versions).
4. For any potential v0.13.x hotfixes, create the PR against release/0.13 branch
5. Then, create GitHub Release targeting that branch to trigger publishing to crates.io

[bobbinth]

Question: why not make the alpha release from next? Basically, update crate versions in the next branch to v0.14-alpha.1, and then make a release from there. Or does this complicate things downstream?

Basically, my thinking is to have main track the latest "stable" release, while next tracks current development (now with periodic alpha releases).

[mmagician]

Question: why not make the alpha release from next?

Thanks, that's a valid point.

The main issue is consistency: today, every* commit to main corresponds to a published release. If we release alphas from next, that invariant breaks - next would get "regular" commits mixed in between alpha bumps.

To preserve the pattern, we'd need a third branch (e.g. dev) taking over next's current role:

dev (development) -> next (alpha releases) -> main (stable releases)

This would work, but adds significant overhead IMO.

---

To sum up, I see three viable approaches:

1. Use main as the latest release (alpha or otherwise). Preserve release/v0.x branch for patch releases. Consistent, and simple.
2. Use next for development and alpha release, main for stable releases. Inconsistent, but also the simplest.
3. Tri-branch process dev (development) -> next (alphas) -> main (stables): consistent, but more complex.

My preference would be to stick with the approach proposed in this PR (option 1). The tradeoff is that main temporarily carries a pre-release version, but that's arguably accurate, as it reflects the latest published state of the crates.

Footnotes

*we're not extremely strict with this rule, but roughly whenever we merge next into main we get a new release.

[mmagician]

Updated release plan summary:

1. Merge this PR to next. After the merge, next will be on version v.14.0-alpha.1
2. Create a release/v0.14.0-alpha branch off the newly updated next
3. Create a GitHub Release with tag v0.14.0-alpha.1 targeting release/v0.14.0-alpha, like so:

4. This will trigger publishing to crates.io

Other changes aside from the version bump:

• I created a new branch protection rule release/* mirroring the one for main
• CI updates: the publish and dry-run workflows were hardcoded to main. I updated them to use github.event.release.target_commitish so releases can be published from any branch (e.g., release/v0.14.0-alpha for the upcoming alpha release, main for new versions).

Going forward

In the call we discussed a bit more radical change to how we track and release our work. I'll write this up in more detail later, but basically it would involve keeping around just one development branch (say main), and multiple release branches (or just tags, TBD), branching off/tagging whichever point we decide to make a new release. Patch releases might, depending on the fix, need to be PR'ed into two branches (the version branch to hotfix, plus the development branch).

The CI changes in this PR align with that strategy, i.e. a GitHub release should be able to trigger publishing to crates.io from any branch/tag.

[mmagician]

Perhaps one outstanding question is: should the development branch have the latest version? Or should it be the version-branch where we change the version? (here I'm going with the former, to later branch off once it's merged to next; but that's easy to change by dropping chore: bump workspace version to 0.14.0-alpha.1)

[bobbinth]

Looks good! Thank you!