Building beta releases

[Taitava]

This is partly the same as #47, but there's less stuff to do, and some things are done differently.

Heading numbers are the same as in #47, although some headings are not present because those sections are not needed.

Deciding a beta version number

If e.g. version 0.8.0 is being developed, and a beta version is wanted to be released before the actual normal release, the first beta version number will be 0.8.0-beta.1. If a second beta is needed, the version number is 0.8.0-beta.2 (and so on). (Beta versions 0.7.0-beta1, 0.7.0-beta2 and 0.7.0-beta3 did not use a dot . in between beta and the beta number, but in later beta versions, a dot . should be used).

3. Update version numbers in the following files

• main.ts: ShellCommandsPlugin.SettingsVersion: Only need to change if the new version changes settings structure. use a normal version here, no beta.x postfix! (Beta versions might contain the future coming version's settings changes, but beta versions themselves do not have "own" settings versions).
• manifest-beta.json: Field name version. (Also change minAppVersion field if needed). If the file does not exist, copy manifest.json to create it. Note that the file must be in the main branch - not in a beta branch (unlike the SettingsVersion change above, which should be done in the beta branch). The version should contain the -beta.1 part, e.g. 0.22.0-beta.1
• Do not edit version numbers in other files. They will be edited later in the normal release process.

4. Create a release in GitHub

1. Commit the changes made in the above sections, with a commit message being something like Beta x.y.z-beta.n.
2. In GitHub, go to Releases and click Draft a new release.
3. Click Choose a tag, then type the beta version number to the field Find or create a new tag.
4. Change Target so that it uses a beta branch you have created, instead of main! (Edit: 2024-01-31: There is no more a branch selector, if the tag name is the same as the branch name. You must select the branch before typing the tag name).
5. Enter the same version number to the Release title field.
6. To the Description field, write: This is not a normal version. It's a beta test version and can be unstable. [See these instructions, if you are willing to participate in beta testing](https://github.com/Taitava/obsidian-shellcommands/discussions/98). Do not use any important vault for testing, because you are not able to convert your data.json settings file back to an earlier version!
7. Upload main.js and styles.css as binary attachments. Do not upload manifest.json or manifest-beta.json - BRAT downloads manifest-beta.json file automatically from the repository's root.
8. Check the This is a pre-release checkbox.
9. If this is the first beta for the futurecoming normal version, check Create a discussion for this release so that you can easily create an announcement about starting a beta test. If it's not the first beta for that particular normal version, you can use the ongoing beta test's discussion.
10. Click Publish release button.

5. Test upgrading

• Open a vault which has an earlier version of Shell commands installed, and BRAT installed also.
• Upgrade the plugin and check that it works and has all new changes.