Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Apps versioning #47

Closed
ra100 opened this issue Nov 16, 2019 · 10 comments
Closed

[Suggestion] Apps versioning #47

ra100 opened this issue Nov 16, 2019 · 10 comments

Comments

@ra100
Copy link
Contributor

@ra100 ra100 commented Nov 16, 2019

I think it will help to have some versioning of the apps, maybe just date/timestamp would be enough. Just something that I'd know, if something changed and that I should upload new version of the app.
And with versions, also changelog would be helpful.

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Nov 16, 2019

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.

@ra100
Copy link
Contributor Author

@ra100 ra100 commented Nov 16, 2019

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 :)

@marcocastignoli
Copy link
Contributor

@marcocastignoli marcocastignoli commented Nov 19, 2019

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

@ra100
Copy link
Contributor Author

@ra100 ra100 commented Nov 19, 2019

@marcocastignoli Would submodules work with github pages?

@marcocastignoli
Copy link
Contributor

@marcocastignoli marcocastignoli commented Nov 19, 2019

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

@marcocastignoli
Copy link
Contributor

@marcocastignoli marcocastignoli commented Nov 19, 2019

@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

@ra100
Copy link
Contributor Author

@ra100 ra100 commented Nov 20, 2019

@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.

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Nov 20, 2019

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

@marcocastignoli
Copy link
Contributor

@marcocastignoli marcocastignoli commented Nov 20, 2019

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

@gfwilliams
Copy link
Member

@gfwilliams gfwilliams commented Jan 17, 2020

Versions now added, just need #79

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants