Plugin annotation, minVersion and target fields

Please for the love of god add some kind of minServerVersion field to the @Plugin interface so that we can reduce the number of people asking why plugins refuse to work with certain versions in the future.

I guess it would be possible to store server versions in an enum or even just a String and compare it with the server version when the plugins are loaded then throw an exception if the plugin is incompatible with the server version?

I doubt it’s worth it but if you know that certain changes in an update would end up breaking your plugin then I guess a maxServerVersion field would be appropriate too so that people know if they go past version X the plugin will stop working.

Interested to hear what other developers have to say on this.

EDIT: Scroll down a bit to see the idea of target instead of maxVersion or click here.


I like this idea. Back when I was doing Android apps I saw this feature and loved it. For android they used something like

<uses-sdk android:minSdkVersion="integer"
          android:maxSdkVersion="integer" />

I would love to see something like that with Sponge plugins :slight_smile:


Glad somebody agrees :smirk_cat:
The amount of times I saw people post on Bukkit forums because they couldn’t get a plugin working with build X (even though the download page specified it was for build Y) was sad.

1 Like

As server Admin, That will be awesome to know what is the max plugin version
Up !! ^^

1 Like

Also as a server owner it’d be nice to know the maximum plugin version as a lot of versions don’t get updated and with the new UUID update a lot of plugins broke and nobody ever really edited their plugin pages saying “Works after UUID change” so there was a lot of download and fail for probably a lot of people, and it could even have a voting system for example:

Let’s say in the future a huge change gets added that changes plugins like UUID’s.
There could be an area for plugins that is updated by Sponge developers that will add an option that says “UUID Compatible?” and if the developer doesn’t say yes or no, the community can vote(In case of inactive author/discontinued plugin) if it’s compatible or not, and this will limit the questions of “Does this plugin work for 1.7.9???”.

Just my two cents.


Exactly what i though :slight_smile:

This is a fantastic idea. +1

The issue with ‘maximum’ versions is you don’t really know if versions that don’t exist yet will work or not, so it’s only really useful if you’re intentionally releasing for an old version.

It should be possible to specify min/max Sponge versions if the dependency stuff gets exposed though.


I upvote this. :slight_smile:

Kobata voices my main criticism with this idea. While a minimum version is certainly reasonable (as long as it’s used correctly by plugin devs), a maximum version is inherently flawed, since a plugin release can’t know about future changes to the API.

Depending on how SpongeAPI intends to be versioned, and how it intends to deal with backwards-compatibility (Bukkit was pretty good at this, but it was constrained by it), it might be possible to come up with some way to know which if any plugins are broken by major changes.

i agree with @kobata as well. Minimum sponge versions would make sense, but having a max would just be like bukkits system where the supported version was the supported version when released even though they still work on higher versions of craftbukkit

I disagree with having a maximum too. That’s predicting the future.

edit: a use case might be releasing versions for older MC versions where a maximum would make sense, but then someone will probably screw that up and set a maximum when they shouldn’t

1 Like

I’m not sure how this’ll work in Sponge… But, with Bukkit any plugin which used NMS was guaranteed to break when the next version (of Minecraft) came out. This was made intentional by putting the version number in the package name.

Plugins which use this technique by @mbaxter know quite well which versions they’ll work with, past and future.

I think maximum version is very useful for this, however I can see it being abused… Plugins which do not touch NMS should generally not have a maximum version.

EDIT: to ensure it’s abused less, it could be named getMaximumVersionISwearIAmUsingNMS()

The main reason for the maximum was simply if you’re updating an older version of the plugin or writing for older versions of the server :smile:
Hope that clears things up.

Nice to see that everyone agrees on a “minimum version-tag”.
But i think, a “maximum version-tag” could make sense, too.
Imagine following scenario:
I’ve developed a super cool plugin v1 for spongev1 so both tags woud be “spongev1”, and i’m still working on new super cool features.
But suddenly the API changes a little bit with spongev1.2, but i want to finish the new features first than updating to spongev1.2 -> My Plugin would need the min-tag as “spongev1” and my max-tag on “spongev1.1” and not yet “spongev1.2”


Annotations can have optional values with defaults, just set the max version to default to the latest version if not specified.

1 Like

I really like the idea of having a min-version, especially when the API is subject to change. I don’t think there should be a max-version though, because a dev could set a max-version and after just abandon his plugin. The NMS hooks Forge will be offering wont be breaking with every update so using that wont be an issue anyways.

By maximum, I didn’t mean like I release the plugin in 1.8 and then set that it wont work on 2.5, what I meant was let’s say I abandon/stop working on the plugin out of no where, never return to this site, and now the community can vote/ask for a page to be updated that says “Hey, this plugin isn’t available past 2.1”

I agree with the min version but I too believe that a max version should at the very least be some sort of optional feature for the plugins. We could have a plugin declare a min version that if the server is not at or above that version the plugin will simply not load and if the plugins max version declares that say the plugin is meant for 1.7 but the server is running 1.8 the plugin could simply warn in console that it is not up to date and some features may not work as intended.

For the versions I would suggest using Strings instead if integers, so we can allow things like the composer project (I’m a PHP programmer as well): Basic usage - Composer.

It would allow to not only match certain versions but also wildcard versions, minimum version requirements and max versions at the same time. That way we don’t even NEED a min and max version number ;).

This would require to have valid strings and versioning though.

1 Like