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