Great! All that needs to happen is the .mmplugin file needs to appear in the Releases (here: Releases · Ericxgao/metamodule-nozori · GitHub)
You can manually create a release (“Draft New Release” button) or you can use a github workflow to do it automatically. I have a sample workflow file and some screenshots to help with that process in the release README: metamodule-plugin-sdk/docs/release.md at v2.0-dev · 4ms/metamodule-plugin-sdk · GitHub
The other thing is to follow the naming convention outlined in that document when you name the .mmplugin file. This helps our website knows which version is which (e.g. dev-12 or some other dev, or if it’s a v1.x plugin). Also good naming helps users know if they have the latest version or need to download a new one, and which firmware a given mmplugin file will run on.
The mmplugin file needs to be named like this:
[BrandSlug]-v[plugin-version]-[sdk-version].mmplugin
So it could be Nozoid-v0.2-dev-12.mmplugin
for instance if it’s built with the dev-12 SDK and you want to call your build “v0.2”. Then the next release you make, you will bump your version up, perhaps to Nozoid-v0.3-dev-12.mmplugin
. When we release dev-13 (soon), you’ll need to re-compile with the new SDK and call the file Nozoid-v0.3-dev-13.mmplugin
Once we have v2.0 as official, then the tag will change from dev-13
to fw-2.0
.
Yes, that’d be great, just PM or tag. I’ll run the scan+update script which will check your repo for new releases and put them on our site.
We also will periodically scan for new releases, so if you publish anything new that matches that naming format, then it’ll eventually end up on the site even if you forget to tell us.
If by change you want to publish a release but don’t want it on our site, you can mark it as a “Pre-release” or just don’t use the exact naming convention.