Rust Audio

Versioning and Releases

The vst crate is currently on version 0.0.2, using semantic versioning.

As we move forward, we should have a system in place for making sure new releases - especially to crates - is seamless. We already have CI deploy on a tagged commit to master which is awesome.

Currently, we are merging PRs directly into the master branch, and haphazardly tagging when we feel as though another release is worthy. We should set up something more cohesive so it is easier to follow, from a development and end user standpoint.

As an example, Zola by Keats sets up a branch called “next” where all PRs are merged into before being merged into master with a tag. I like this system (especially in junction with a roadmap) since it makes it very clear what is in development.

This is just one example, though. What are y’alls thoughts? Do we need a system in place? Is the way we do things now fine? Is there something else I’m missing?

Yep, this sounds pretty good to me if we have a roadmaps system (that or a “release train”-style schedule, but I think we’re too slow for that at the moment) – if we don’t then it’s the same problem with a different workflow.

IMO we should probably have a new version for (almost) everything that goes into master though, especially anything that breaks API (which is fine in 0.x.y releases) so that people can target that old version and not have their VST suddenly break underneath them.

1 Like