Version numbers of plugins
#1
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)?
Reply
Thanks given by:
#2
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.
Reply
Thanks given by:
#3
(10-03-2015, 11:59 PM)NiLSPACE Wrote: 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.
Reply
Thanks given by:
#4
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
Reply
Thanks given by:
#5
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.
Reply
Thanks given by:
#6
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).
Reply
Thanks given by:
#7
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?
Reply
Thanks given by:
#8
@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.
Reply
Thanks given by:
#9
It would be nice to have some kind of dependency management for plugins
Reply
Thanks given by:
#10
(10-09-2015, 07:21 PM)xoft Wrote: @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.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)