Examples on how to use version numbers safely

[holroy]

Currently dataview is on version 0.5.68, and I've started dreaming about 0.6.x version, and I'm finding myself wanting to branch of and start releasing beta versions on a dev-0.6 branch. The question then becomes how do I do that with a publicly available plugin, and without interference on the master branch.

I do want to be able to release minor bug fixes and so on related to the official version, in addition to releasing beta releases related to the 0.6 version.

I've already got a setup with manifest-beta.json, but I'm uncertain on the releasing from a branch, and how to do version numbering without causing issues here and there. So is there any suggestions on how to move forward in such a use case?

Can I just keep releasing 0.5.69, 0.5.70, ..., and in between release something like 0.6.0-alpha-1 from another branch using BRAT?

[johannrichard]

I think there are two questions that are somewhat, but not completely, related:

1. to develop the new features on a (beta) branch,
2. to release previews of the plugin, and the role of BRAT in all this.

Specifically:

1. New features developed on a (beta) branch: yes that should be the way to go. It's probably obvious: you'll have to keep track of any bugfixes in the current MINOR and its PATCH versions (0.5.x) that need to be brought into your pre-release branch (0.6.x-alpha.y). Also, strictly speaking, you'd want to stick to releasing bugfixes only on your main branch (patch release): in semantic versioning parlance, any feature(s) released should bump the MINOR version by one, but not something enforced by anything.

2. Release the preview from a branch: with the updated BRAT, this has become easier as we don't depend on the manifest-beta.json and therefore don't depend on committing to your main branch to release a beta version anymore. BRAT will pick up the latest pre-release (However we are still sorting out how to deal with version numbers that are not fully compliant semantic versions. Currently we would always install the latest (as in creation date) release which could mean a user would be downgraded in case of an intermediate release on 0.5.x after a 0.6.x-alpha.y release. This will be fixed in an upcoming release).

You might want to use something like semantic-release to build these (preview) versions in an automated way, but you can of course also use other automations. Not sure how much you're aware or knowledgeable about these. There are a few caveats, including how to deal with commits to manifest.json and package.json across branches and releases.

[johannrichard]

@holroy to build releases locally, while adhering to semantic release version numbers, you might also want to look at release-it: in comparison to semantic-release I found it easier to use it for a local-only (or local-first) approach:

• It is menu driven (so you know exactly what's going to happen, and why),
• It will prepare everything up to a draft release on GitHub where the only thing that's needed might be some touches to the release notes and to add (upload) the assets which were built locally to that draft.

I wrote up a Gist for Local Obisidian plugin releases with release-it that should get you going in no time.

(If you have created a GitHub Workflow that builds a release based on tags, you might want to either disable it or edit it such that "pre-release" tags don't trigger it. Reason is that pre-rereleases won't modify manifest.json in the root with the provided script, and hence the tag will be added to the last commit. And since this one does usually not contain the [no ci] marker in the commit message, the GitHub workflow will be triggered and a regular release will be created).