What's Changed
- feat: ✨ use manifest from latest valid github release for BRAT by @johannrichard in #93
- feat: ✨ fetch available versions into dropdown when adding frozen version by @johannrichard in #96
- feat: ✨ allow user to update frozen version by @johannrichard
Full Changelog: 1.0.6...1.0.7-preview.1
By using the github releases instead of manifest-beta.json? the plugin will:
- download a specific forzen version if specified (independently of whether it is defined as “pre-release” or not), or
- download the latest version available as a release or pre-releasae, giving priority to the highest version number according to the semantic version rules (see below)
Specifically, it will fetch the manifest.json from the latest (pre-) release in the repository to install and update plugins.
This makes BRAT independent of the version numbering in the repository root, and allows developers to use semantic-release and beta branches to develop pre-releases that all work with BRAT. (PR #96 will implement a means to more easily select a specific release as frozen release, eventually with the possibility of manually switching between releases as well)
BREAKING: manifest-beta.json is not necessary anymore, although having it in a repository doesn't hurt at all. IMHO the change is still backwards-compatible with the old way of the plugin.
As far as I can tell, Obsidian and plugins like the Obsidian plugin tracker currently look at the master manifest.json in the default branch of a plugin repository when updating plugins, which is also compatible with this change. If a developer releases a “beta” version as an independent but “full” release in his repository (e.g. by manually creating it), BRAT will pick it up independently of the version number in the master mainfest.json of the repository.
Furthermore, this change might also solve #81 and help with #61 as BRAT will download the latest official release automatically if there is no newer pre-release.
It will also make BRAT more robust, as it will always use the true release list as its source of truth.
Finally, it will work nicely with semantic-release in general and brianrodri/semantic-release-obsidian-plugin in particularly: any successful build of a (pre-)release (beta and similar) will be picked-up by the plugin automatically. To make a concrete example. With an alpha, beta and preview branch, the highest preview version would be preferred over beta or alphaversions, ensuring people using the plugin without frozen versions will get the most stable pre-release (and highest release, if available):
| Semantic Versions | |
|---|---|
| The results of a Semver comparison from lowest to highest version | |
| 1.0.0 | 1 |
| 1.0.1-alpha.25 | 2 |
| 1.0.1-beta.5 | 3 |
| 1.0.1-preview.1 | 4 |
| 1.0.1 | 5 |
Also note that there is an inconsistency in Obsidian's Plugin doc vis-à-vis version numbers: They reference Semantic Versioning but insist that versions can “only use numbers and periods (.)”. Valid semantic beta version numbers also contain dashes (e.g. 1.2.3-beta.1). I'd argue the latter is valid and therefore can also be used for Obsidian plugin versions, at least while developing. BRAT will take care of that, however it might be Obsidian itself will not yet do so.
How to test
You can test this BRAT pre-release by bootstrapping BRAT into itself:
- Add a new
frozenversion of BRAT with repositoryTfTHacker/obsidian42-bratand version number1.0.7-preview.1 - BRAT will update itself in Obsidian making the new functionality available
- Remove the frozen version (if you wish)