Discussion related to multiple API version(or just multiple jar) support per plugin release/version

[parlough]

This is a blanket issue for discussion on how to handle releasing a plugin version for different API versions which may require multiple releases/jars.

It is currently a pain to do this as you need to make multiple releases which have different plugin versions.

Eventual support for Maven as well as general API usage needs to be considered.

Some initial discussion around this has started, and a possible solution has come up to allow multiple jars per release, while utilizing maven suffixes(classifiers?) of some sort per API version.

While considering this, with multiple jars per release, supporting an API jar(API for the plugin not Sponge) should be considered while planning and discussing, as many plugins do have an API and it is not necessarily the best idea to require a separate release or a completely separate plugin for the API. It would be great to be able to tie the proper API release to the plugin version it was made for by being able to include it in the same release. This also provides an easy identifiable location for those who actually want to use the API.

[mbax]

If we're going to go the maven repository route, which I'd really like to see, then versions themselves need to be unique. That said, what about the classifier property when talking maven? I don't see it used often but it could be the solution for multiple files with the same version but different API support.

pluginname-1.0-SpongeAPI5.0.jar
pluginname-1.0-API-5.0.jar

Technically all things under same version are meant to be built from the same POM. I'm sure some plugins would actually do things that way by using modules, but maybe not all.

[progwml6]

classifier support would be needed at a minimum in order to allow multiple versions, javadocs, sources, api jars, etc. for mavenization down the road. ore will simply need to be taught how to recognize those types of things based on the filenames, and mcmod.info files.

[ryantheleach]

It was my understanding that the classifier directly tied into the channels in the original design. But maybe I'm getting terms confused.

[progwml6]

I have no clue what the original design does relating to this, or doesn't do and want everything verified so that we don't have more of these vanishing file issues, and can support both classifier/channel based activity and secondary jars(javadoc/api/source)

note: channels shouldn't really be immutable either, as on curseforge for my forge mods I tend to promote jars up from alpha > beta > release channels if I find them stable enough instead of building new ones for that, I wouldn't be surpised if others want to similar things on ore