Yes, that's come up - versions would definitely be handy, especially if they were read back from the device so you could see if updates were needed.

I guess one option is to just version them based on number of commits to the app's files - but maybe just having a version number in there is easier. I guess if they were all in separate folders then a changelog would be easier too.

I was thinking too, to version by commit number, but that would mean, to check the latest change from multiple files or folder. Which shouldn't be a problem, on the other hand, having manual semver, where author would specify what is the "level" of the change would give more freedom and be more human readable :)

What about using git submodules for the apps splitting them into multiple repositories?

@marcocastignoli Would submodules work with github pages?

That, sir, is a good question 🤣 I can make an experiment!

@ra100 they work properly

This is the container repo: https://github.com/marcocastignoli/github-pages-submodules
This is the submodule repo: https://github.com/marcocastignoli/github-pages-submodules-module

This is the github pages url to access the submodules files from the container repo: https://marcocastignoli.github.io/github-pages-submodules/github-pages-submodules-module/index.html

@marcocastignoli wow, nice, so it will be a nice option, for those more advanced in git. Maybe we can just update README.md with how to work with submodules, if @gfwilliams will agree.

Is your idea that git submodules will always point to a specific revision (not just HEAD)?

If not I'd be a little concerned about allowing unvetted code (at least until there's a default-off option to enable 'untrusted sources') as someone could conceivably update an app in such a way that it would brick Bangle.js without anyone knowing.

So obviously it seems like a cool idea, but could you tell me what benefits this actually has over a single repo?

I guess I see a few bad points:

• If always on master, the possibility of adding dangerous/broken code with over oversight
• If not, one commit is now two (update the app repo, update BangleApps to link to the new commit)
• Possibility of repo just removed by the owner and leaving non-working apps
• Versioning issues (if the version isn't in apps.json then BangleApps will have to download and parse JSON from hundreds of different repos on startup)
• It's far easier for people to push stuff that they haven't tested. Right now it's trivial to pull up GitHub pages and check everything out before you update

Is your idea that git submodules will always point to a specific revision (not just HEAD)?

It always points to a specific version, and it is handled as another generic file. So, people can make pull request and ask you to update their apps to the specific version, then you can check and merge the pull request.

If not, one commit is now two (update the app repo, update BangleApps to link to the new commit)

This is true

Possibility of repo just removed by the owner and leaving non-working apps

We have to figure out what happens when someone deletes a repo that you added as a submodule, I can experiment that hoping that github doesn't trick me with some kind of cache

Versioning issues (if the version isn't in apps.json then BangleApps will have to download and parse JSON from hundreds of different repos on startup)

That's not a problem, when you update the submodule you also update the apps.json

It's far easier for people to push stuff that they haven't tested. Right now it's trivial to pull up GitHub pages and check everything out before you update

I can't uderstand this

Versions now added, just need #79