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???”.
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.
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
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.
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
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”
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 http://semver.org/ valid strings and versioning though.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Maybe instead of calling it maxVersion call it target instead? Then you could simply warn console saying something along the lines of
[SERVER/WARNING] SpongePlugin “1.7.9-Stuff” was created for an older build of Sponge and may have performance issues.
I think that would be a better compromise due to what the others have previously stated, though I thought maxVersion was helpful incase you only wanted to target [up to] a certain release.
The min/target/max works in Android, and I strongly believe it will work here, too. In fact, it adds a huge search benefit to whatever site Sponge creates for all the plugins/mods because people can search for plugins that are compatible with certain versions of Sponge.
Yes, it can be abused by evil developers, but there are ways to reduce the abuse. For example, (I’m going to use Android Apps as examples alot when it comes to this, because I have a lot of personal experience with this concept on Android) if a dev creates an android app and specifies a min/max (its optional, btw) then the entire platform will only let the app work in those versions. The app wont even show up in the store if its ran on a version thats not within the range. This helps end users from downloading apps that may not work on their system. There is a safeguard in place by Android, also, that will not let the app even work on the store if a version is specified that does not exist. This prevents developers from abusing the system too horribly. When a new SDK version is out, the dev can then specify that version in their app.
Preferably devs should only be specifying tested versions, but not much you can do about checking that. If the dev does not test on a version they specified, the users will find out quick enough and share the information with others.
InB4 “but then whats the point if we have to update the plugin with every version?”: You should not be updating your plugin’s version number just because its become known to work on a newer API/MC version. This is a Bad Thing™ and was done far too often on DBO and was a huge part of the huge backup of the plugin queue every time a new MC version was released. If Sponge has min/target/max versioning all you would have to do is update your min/target/max and re-upload the jar. The queue approvals (if there will even be any) can simply do a quick diff on the decompiled sources to see the only thing changed was the min/target/max and be instantly approved in less than 10 seconds. Heck, this could even become an automated check the site could even do on its own so the file skips queue entry entirely since nothing changed. Android actually goes as far as checking all the lines of code against the API(s) specified in the min/target/max and if any fail the upload is instantly rejected. We have a huge group of talented developers here, so I’m almost certain we can come up with an automated system that helps minimize the abuse concerns.
The benefits of having a min/target/max system are definitely worth looking more into (people smarter than me can run with this idea and make something great for Sponge, I’m sure).
The greatest benefit is the end user can more easily find plugins compatible with the version server they are running. Everything else will remain hidden from them. And especially beneficial for those running older server versions because they wont be overwhelmed at all the newer plugins that are using a newer API.
I just realized how long I’ve made this post, so I’m just going to stop rambling now. :S
