Sponge Versioning Plan

Seeing the discussion bloom over in Plugin annotation, minVersion and target fields - #22 by charries96 I thought that a pretty good point came up.


I personally really like the http://semver.org/ approach. It’s a standard that everybody can understand and is pretty simple to follow. Even if we somehow go up to version 8.2.7 people will understand why when looking at that side: We had too many API breakages - doh!

What do you think?


Just glancing over it briefly I do like the look of it, though I thought we already had some sort of versioning system.

I like the idea of proper versions like this. Plugin yml could go like
name: vampsplugin
main: blah.blah.blah
plugin-version: 1.0.1
min-mc-version: 1.7.10
max-mc-version: 1.8.0

and blah blah
ps not even a plugin dev but I’ve touched on it from time to time and know how annoying it is having to make sure the plugin even works for the proper version you are running

There will be no plugin.yml :wink: And over at the min/max versioning thread we’re even discussing to only have one “target” version.

that makes sense was just an example anyways

for target version though would the plugin specify like oh this was meant for 1.7.10 or just 1.7 in general or what

If you require a feature introduced in 1.7 then you depend on 1.7, which would match everything up to (but not including) 2.0. If you depend on a bugfix introduced in a later version then you’d depend on the version that fixed the bug (let’s say 1.7.5).

Going across major versions would require testing and manual approval.

I like the schematic versioning approach. The problem would be to identify what mc version it is for.

I Think we would stay at 1.X.X for quite a long time, and after some time we would be at 1.57.3, which isn’t very nice.

True. Bukkit was named per-Minecraft version with “x.y.z” but I normally compared build numbers when comparing two versions of Bukkit for the same Minecraft version.

I see the advantage of versioning based off Minecraft’s version, but I personally see it as more of a downfall than a benefit. It helps server owners, but it is a separate piece of software and as such shouldn’t need to be versioned with Minecraft in mind.

I personally would not really dislike that. Heck, if MC added so much stuff, but we can still proceed and have no API breakages at all - there could be a 1.132.12 even. As long as it makes sense.

1 Like