Quote:
Originally Posted by mpl
I may not figured it properly, but if we say about spreadsheet it is a good idea if it comes with repo and used by updater. But it is hard to merge pull requests and edit this spreadsheet simultaneously.
|
I think too that maintaining such a file by hand is bad. Ideally it should be maintained automatically like Homebrew does to update their "bottles":
Example:
https://github.com/Homebrew/homebrew...2d62ba58d9c55d
GitHub hooks:
https://help.github.com/articles/about-webhooks/.
It does not seem too hard to implement, but the weak point is that the automatic maintainer bot must stay online permanently for free (if it goes down, spreadsheet updates goes down temporarily until somebody notice and fix... not ideal anymore)...
Quote:
Originally Posted by mpl
Maybe it should works with repo nominal versions (again like SWS), and not update with every commit.
|
Yes that's a better idea at least for now (because it doesn't require to keep a bot/server online).
The difference is that instead of seeing one script updated every day, user would see a batch of 30 updates but only one day per month (no big deal right?).
Review of these two scenarios:
1/6. Pull request accepted and merged -> goes to the automatic script for processing
-- or --
1/6. Automatic release script is ran by a human maintainer every now and then
2. Does this pushes a new version of a script? (version metadata changed)
3. If yes, continue:
4. Insert the new version data in the database (download url and changelog)
5. A short while later the REAPER extension fetches the new database and notice the update
6. User is prompted "Version 2.0 of XYZ.lua is available! Update? <changelog since the version currently installed>"
EDIT: Here's a prototype of the database format I'm working on:
http://sprunge.us/YaAC?xml Thoughts?
(It's made to be generated from the metadata in the script's headers, either automatically by a bot or semi-automatically by a tool ran once in a while by a human being)