Posts: 324
Threads: 41
Joined: Oct 2014
Thanks: 1
Given 20 thank(s) in 65 post(s)
Currently, most official plugins have a version number which rarely changes, even after new updates are released. Wouldn't it be better to use the commit number as the version, or simply remove the versions (from plugins bundled with the main server)?
Posts: 952
Threads: 16
Joined: May 2013
Thanks: 21
Given 16 thank(s) in 89 post(s)
Once I've gotten the plugin repository integrated with GitHub, I'm aiming to set something up regarding for the built in releases system the hub of gits provide, and some automatic injection of version information into Info.lua.
Just imagining the amount of work that's going to take has made me groan :P
Posts: 6,486
Threads: 176
Joined: Jan 2012
Thanks: 40
Given 156 thank(s) in 838 post(s)
I have had a different vision for version numbers altogether for a while. How about this:
The version that is declared in the plugin's Info.lua file is an "internal" version, used mainly for inter-plugin compatibility check ("GalExport plugin v.5 needs Gallery plugin at least v.7"). Version that is visible to the admin should come from an external source, such as the git commit hash, or GitHub release tag, and as such shouldn't be stored in the plugin at all.
Posts: 4,621
Threads: 113
Joined: Dec 2011
Thanks: 51
Given 55 thank(s) in 409 post(s)
I don't think that's smart to do either. For example if a plugin is outdated and gives a message in console: "WorldEdit is outdated. Download version d8127aa". What should the admin do with that? He might not even know it's a git commit hash. I don't really know what the release tag is, but if it's something readable then I guess it could work.
I'd rather have 2 values in the Info.lua. One that is visible for admins and easy to compare (0.1.5), and one used internally for plugin compatibility checks (9).
Posts: 952
Threads: 16
Joined: May 2013
Thanks: 21
Given 16 thank(s) in 89 post(s)
Alright, how about, as with Universal Windows apps, have the internal version incremented automatically (by the repository) when there is a new GitHub release, and have the external version set to the release tag?
Posts: 681
Threads: 26
Joined: May 2014
Thanks: 0
Given 8 thank(s) in 37 post(s)
It would be nice to have some kind of dependency management for plugins