I’m trying to get Pamplejuce (my JUCE plugin template that builds/releases in CI) into a 1.0-ish place, and the versioning workflow is something I’d like to improve.
Right now we have a VERSION file that contains the version number. It’s propagated to the app. To get a release cooking in CI, you also need to create a git tag and push (which is clunky and I’ve never really liked).
If anyone uses Pamplejuce (or would like to) and wants to weigh in, now’s the time.
I wrote up a couple workflows and would be interested if anyone else uses one they like: Improving Releases, tags and handling of the VERSION file · Issue #44 · sudara/pamplejuce · GitHub
–
There’s also some interesting conversations around breaking changes and major versions. For example, for my projects, I append the major version onto the target and product name like so:
set(PROJECT_NAME "MyPlugin_v${MAJOR_VERSION}")
PRODUCT_NAME "My Plugin v${MAJOR_VERSION}"
I’m assuming this would not be well-liked as a default, especially for v1 (since it’s not pretty in the DAW, maybe some plugins won’t go beyond v1 anyway).
However, I do feel like some convention / hygiene around this topic would be great, as it’s a common pain point that modifying dsp, changing parameter ranges, removing parameters, etc is either not possible, or only possible when releasing new major versions (which is what I’d like to facilitate).
Maybe I could make it so it only appends versions starting with v2? Or maybe that would still be surprising to some people (it’s a template, so they can edit it away anyway, it’s more about good convention/defaults).
And then there’s the question of betas. I know some companies will release PRODUCT_NAMES with b1, b2, b3 (again, to not break their user’s projects during testing).