Version numbers of plugins

[Mathias]

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

[NiLSPACE]

I talked about this not too long ago: https://forum.cuberite.org/showthread.php?tid=2121

Personally I like FakeTruth's solution. To have an integer and a string. Then I can just change the version up from "0.1" to "0.1.1" instead of going from version 0 to version 1 for small changes. That's mostly the reason why I barely change the version number.

[Mathias]

I talked about this not too long ago: https://forum.cuberite.org/showthread.php?tid=2121

Personally I like FakeTruth's solution. To have an integer and a string. Then I can just change the version up from "0.1" to "0.1.1" instead of going from version 0 to version 1 for small changes. That's mostly the reason why I barely change the version number.

Oops, I should've used the search function.

[tigerw]

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

[xoft]

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.

[NiLSPACE]

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

[tigerw]

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?

[xoft]

@NiLSPACE, the plugin should just say "download a newer version"; if there is a mechanism to actually get the version numbers, it should also be capable of downloading the metadata about the version (such as the release date, or pretty-version)

@tigerw having version numbers maintained by the repository is always a difficult problem, because of updating them in a platform-independent way. That's why I propose we don't even store them at all, and use the metadata about the commit to specify the version.

[sphinxc0re]

It would be nice to have some kind of dependency management for plugins

[tigerw]

@tigerw having version numbers maintained by the repository is always a difficult problem, because of updating them in a platform-independent way. That's why I propose we don't even store them at all, and use the metadata about the commit to specify the version.

The repository is platform independent, no? In any case, something about the commit of the plugin needs to be stored.