+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html)
+--- Thread: Implementing a plugin updater + dependency management + semantic versioning (/thread-2334.html)
Pages:
1
2
Implementing a plugin updater + dependency management + semantic versioning - sphinxc0re - 01-28-2016
Hello
Since our WorldEdit clone now has an automatic updater I once again thought about implementing one into the server, that supports updating plugins by using semantic versioning (http://semver.org/)
I'm imagining a file called plugins.txt
Code:
Core@8.0.1
WorldEdit@2.1.0
Essentials@3.1.2
...Plugins would have to use semantic versioning in their info.lua
RE: Implementing a plugin updater + dependency management + semantic versioning - NiLSPACE - 01-28-2016
I still don't think it's the server's job to update plugins. What could make sense though is implementing it in a different plugin or in Core.
Though I don't really know what you want to do with that plugins.txt file. What would it be used for?
Also, I could understand people wanting to use "beta" or "alpha" in their plugin version. Are we going to rob developers from being able to do that?
Another thing we might want to consider is that some developers might want to use a fast lane or slow lane like with the Windows preview builds. The fast lane gets new features rather quickly, but it's possible that there are still bugs in there while the slow lane gets less features but is more stable.
RE: Implementing a plugin updater + dependency management + semantic versioning - sphinxc0re - 01-29-2016
You really didn't read the specification, did you?
RE: Implementing a plugin updater + dependency management + semantic versioning - NiLSPACE - 01-29-2016
I probably should reword it a little (though I did miss the beta/alpha in the specifications, sorry), but it all comes down to this: What if people don't want to use semantic versioning. I mean, we can't really force them, only encourage it.
I also still don't really understand the plugins.txt file.
RE: Implementing a plugin updater + dependency management + semantic versioning - sphinxc0re - 01-29-2016
No, we can't force them. We just say, that if they won't use it, their plugins aren't gonna be updated. The library I mentioned to you, is able to detect this. The plugins.txt file would contain the whole plugin configuration and it functions as a lightweight plugin backup. Whenever you move or update a server you can just move the file with you and the server automatically downloads the plugins
RE: Implementing a plugin updater + dependency management + semantic versioning - NiLSPACE - 01-29-2016
Here is the library SphinxC0re mentioned: https://github.com/zmarko/semver
Though as I said I don't think we can use it because it uses C++14 while were using C++11.
So you'd save the name of the plugin, the configuration file, (database possibly?) and a link where it can be downloaded? This would also mean that developers needs to mention where the configuration file (and possible the database) is. I guess that's possible, but I still don't think we should hardcode an updater inside the server. It makes more sense to me to let another plugin handle it.
Also, I don't think this change would, but I'll mention it: Would this change break our current plugins?
Finally I'd like to point out that I'm pretty frustrated that we're getting this discussion after I've finished my updater functionality in WorldEdit. I mean, come on the PR was there for 9 days, couldn't we talk about it back then?
RE: Implementing a plugin updater + dependency management + semantic versioning - LogicParrot - 01-29-2016
Important: Regardless of what is done, I think this should be planned very carefully and sestimatically. We don't want each plugin reinventing the wheel with its own update system, and we don't want to end up with fragmentation all over the place. It should be planned in such a way that even an inexperienced plugin developer can tap into the system.
Again, I think we should thoroughly discuss this and plan it very carefully before writing code. I would really like to help out here, both in code and planning.
I believe the new plugin website was done hastily. Firstly it did not implement categories, and secondly, it was created without plugin updaters in mind.
Perhaps an ideal system would have a website with a rest api, and a cuberite-sided plugin (or cpp code) which uses the API for update checking, and allows admins to browse for plugins right through the webadmin and install them with one click.
RE: Implementing a plugin updater + dependency management + semantic versioning - LogicParrot - 01-29-2016
Among other things, api versioning should be considered; A plugin updater shouldn't update a plugin to a version which the server does not support.
RE: Implementing a plugin updater + dependency management + semantic versioning - xoft - 01-29-2016
I think the plugin updater should be implemented in a separate plugin, and it should be tied to the plugin repository. The plugin repository should really keep track of the versions and whether they are "beta" or "release" grade; the updater will have a per-plugin setting which grade to use.
As for version numbers, I still think a single number is the best solution, like in Android; the plugin repository would have the database of which version numbers are considered "release grade". It makes comparisons simple, no library is needed. It could even be made so that the actual plugin has no knowledge of the version number, only the updater and the repository keep track of those.
RE: Implementing a plugin updater + dependency management + semantic versioning - Schwertspize - 01-29-2016
I would prefer a plugin install (maybe via webadmin) which clones a git repo. The autoupdater can then simply check for new commits. Additionally the auto updater can ignore directories not available as git repo.