Developer enhancement: ability to have a “Release” and “Beta” release for a plugin

I have now finished 3 plugins, and really enjoy the API. A big pain point though has been in updating testers with newer builds since it requires manual steps. For some users its confusing, for some users they just don’t have the time for doing the updates.

Proposal:

  • Developer can define in manifest.json a “beta” release
  • User can for an installed plugin opt-in to getting the beta release over the live release. (Some kind of toggle to enable beta release usage)

The manifest could appear as:
{
… other details
“version”: “1.0.2”,
“Beta”: “1.0.3”
}

If Obsidian finds a beta release upon a check for updates, and the user has enabled using betas for this plugin then Obsidian would update to the beta release. Of course if the user turns beta off, or if there is no beta parameter in manifest.json, the normal release is used for updating.

This would reduce many challenges of properly testing a plugin before updates go out.

One additional bonus would be if a user manually installs a plugin before a plugins release, that it could be updated as well if the manifest has the beta parameter.

Thank you for considering this request. I believe it can lead to better testing and user experiences from plugins in Obsidian.

Consider this my “October” contribution to the community :slight_smile:

16 Likes

I can see this working for already released plugins. I think it would be harder for pre-releases because those aren’t in the obsidian-releases repo yet.

I support this for released plugins and suggest we split the prerelease functionality into its own plugin that runs through manifests and checks the current release against the release in GitHub.

4 Likes

You inspired me. I might build this.

2 Likes

So… built this plugin