Feedback on plugin versioning/naming

Dev Firmware Discussion
1

So we’re almost ready to release v2.0-dev-13 which I’m considering as a release candidate for v2.0 since there are no more planned changes to the API.

I’m wanting to get feedback on a proposed system for plugin versions. This effects the autoloader and manual plugin loader, and also how plugin files are named.

Plugin tab

Currently the plugin tab filters out plugins it thinks can’t be loaded by parsing the version in the filename. The proposal is to get rid of that and just display all the plugins it finds. This way you, as the user, can decide which one to manually load.

The downside is that if you go back and forth between incompatible versions a lot, and you are doing a lot of manual plugin loading (not using the auto-loader) then you’ll just need to scroll past a lot more to get to the right one. To make that easier, you could put them on separate SD cards or something. Or, one thing we could add is to have a plugin folder convention, like metamodule-plugins-v2 will only be seen my firmware v2.

Autoloader

Right now the autoloader attempts to parse the versions and pick the latest one that it thinks is compatible. However, this is not worked out to be totally accurate and is a point of confusion during development.

The proposal here is to make the autoloader more dumb. It will just sort the plugins by version (using SemVer) and attempt to load the latest plugin version it finds.

For example, if the autoloader scans all the disks and finds:

  SupaPlug-v1.2-beta7.mmplugin
  SupaPlug-v0.1.mmplugin
  SupaPlug.mmplugin
  SupaPlug-v0.9-dev-13.mmplugin
  SupaPlug-v0.9-dev-12.mmplugin

Then it will attempt to load the one with v1.2 because that’s the latest version. If it fails to load this one, then it will not try any more.
We might add a feature to make it try more versions until one succeeds. (e.g. next it will try v0.9-dev-13, then v0.9-dev-12, then 0.1, then the one with no version).

Plugin file name

The proposal here is to require plugins to be named like this:

[BrandSlug]-v[plugin-version]-[sdk-version].mmplugin

The plugin-version is anything the plugin developer wants to use to keep track of updates/bug fixes, as long as it starts with a -v and is in SemVer form (e.g. 1.2, or 1.2.3, or 1.2.3-beta-2)

The sdk-version is either -fw-X.Y for officially released firmware, or -dev-Z for development firmware. The difference between the two is we keep dev firmware plugins more hidden on the webpage since the firmware they run on is not yet considered stable enough.

E.g, there might be a release for official firmware and the latest dev firwmare like this:

Plugin-v1.2-dev-12.mmplugin
Plugin-v1.2-fw-1.6.mmplugin

The file name is important so you can look at a .mmplugin file you downloaded and (1) know if it’s later or earlier than the one you already have by looking at the -v part, and (2) know if it will run on the firmware you’re using, by looking at the -fw-X.Y or -dev-ZZ part.

Strictly speaking, if you read carefully above how the manual plugin page and the autoloader work, then you’d see that these version strings aren’t necessary to run a plugin on the MetaModule. But they are necessary for the plugin to be released on our plugin webpage since our script uses that information to know where to place the plugin, and to make sure we’re linking to the latest versions.

Any feedback on this is welcome, from users or plugin devs. There may be some use case we’ve left out or are missing!

More info on releases is here:

1 Like
2

From a user perspective, I think this would be a good feature. But the UI of picking the version you want is pretty awkward — especially if the plugin has a long slug, in which case the version numbers are pushed off the screen and you have to wait for them to scroll. It’s hard to compare a set of numbers that are all scrolling on different cycles!

So here’s a suggestion: When there’s more than one version of a plug-in, instead of listing them all, give me two options, the latest version and [see versions] with a disclosure triangle.

So your SupaPlug example would look like this:

SupaPlug
[see versions] ⏵

If you select SupaPlug, it attempts to load the latest version (i.e. v1.2-beta7) and gives up on failure. Whereas if you select [see versions] it displays this:

SupaPlug ⏷
  v1.2-beta7
  v0.1
  [no version number]
  v0.9-dev-13
  v0.9-dev-12

(I’ve removed the .mmplugin extensions; there’s no reason to display them as far as I can tell.)

3

OK that’s a good idea to display multiple versions in a hierarchy.

I did reformat the plugin list so the version gets its own line (no scrolling, unless it’s much longer than the longest versions we’ve seen yet).

Screenshot 2025-03-31 at 9.11.47 AM
Screenshot 2025-03-31 at 9.11.47 AM638×480 48.6 KB

4

Oh yeah, much better. Sorry I missed that, I’m a few versions behind.

5

From a non technical perspective, what is the difference between development and beta. Do we even release alpha codes? For naming convention, i suggest as follows.

Name of Plugin-x.xx (y)

X to represent version number and sub versions.
(Y) to appear only if it’s a beta.

Example: Supaplug-2.01(beta) or just Supaplug-2.0, which should be inferred as official release.

6

“development” refers to the MM firmware whereas “beta” might refer to the plugin itself.

7

Just call it MMFirmware-x.xx (y)?

9

It’s helpful to know if a plugin is for the development firmware or the release firmware though.

EDIT: I think i keep misunderstanding you, but there’s two independent development processes, each with its own versioning, and it can be useful to have all that information in the plugin name.

10

We use "development " to refer to the unstable firmware version that’s not officially released yet but is available for brave souls to download and try out some new features. We don’t use the term “beta” except sometimes I introduce the development firmware as “beta” (in quotes, usually) because I think it might help people understand that it might be buggy and is subject to change.

11

Just giving my suggestion. Last one. Since there are separate tracks for firmware and plugin developments, there might not be a straightforward naming method.

I can think of bundling plugins that “should” work with a particular version of firmware together as ONE download. It isnt much better I know but many times I observed brave souls having to back track.or do a double take only to find out that the versions were different or not compatible.

So it depends on what problem statement you wanted to.solve.

12

[quote="Starscream, po

Right, it’s also helpful to know months from now if that “SupaPlug-v2.0” file that you have on your SD card is for some old version of firmware, or if it’s for the latest version.

13

@gabrielroth I started implementing your idea to group the plugin versions:

Screenshot 2025-03-31 at 7.37.31 PM
Screenshot 2025-03-31 at 7.37.31 PM634×478 51.3 KB

The plugins are sorted alphabetically, and within each plugin it’s sorted by version newest → oldest.

If you pick a version to load, it will remove all the other versions (which wasn’t the case before).

I’m actually not sure it needs the dropdown arrow (“show all versions”) since the newest is always first. Maybe we could fit take a “LATEST” icon of some sort? Also the dropdown would take up a line, which means we’re only saving space if you have 3 or more versions. I might leave it like this for the release and if after using it, we think it needs a show/hide then we can add that.

1 Like
14

The 2 types of MM users, KISS and bleeding edge. Sounds like ringfence the first as described in the Supaplug and open slather on the second under “Advanced Options”

15

Yeah nice, this looks really usable.