Plugin naming scheme?

Currently many plugins use their own naming scheme.
I want to suggest a unified naming scheme here to make choosing the right plugin version for the desired sponge version easier and to iron out compatibility issues between newer spongebuilds and older plugins.

My suggestion is something like the sponge.jar filename, just for plugins:

This way plugins can easily matched with the correct sponge version.

Any thoughts/input?

1 Like

I generally use:

At a certain point, the {sponge-version} would become irrelevant. That’s kind of what an API is all about - backwards compatibility. Of course, with new introductions to Minecraft, certain plugins would need to specify a {minecraft-version}. However, the majority of them are safe enough to assume they’re functional.

obviously the Sponge-version/buildID will become obsolete at some point.
But currently it may come in handy as the API is still changing and plugin tend to break :slight_smile:

I propose the following:

Also, the apiversion is a factor. And it always will be. As much as we try to avoid changing the API, Minecraft will change and the API will have to adapt to it.


When building a jar for testing puposes, it would be really helpful to have the githash/branching information.

Is it possible/feasible to get the current git branch when building a sponge jar?

Clearly this shouldn’t be in any release builds to avoid confusion, but could clear up debugging if people are reporting issues on micro-forks of sponge.

That is indeed possible. It’ll be more / less complicated depending on how you shoose to build it. Some buildsystems for instance will provide it as an instance variable. If you want to make it run in all environments, you’ll need to retrieve it in the buildscript. It’d probably make sense to include a commit hash of the commit that was build into the plugin name. (assuming the plugin has a git repo)

Also there’s a gradle git plugin
See here:

oh, I got off topic and was thinking about Sponge’s versions, sorry.