This latest missive of the SpongePowered team
Will be issued in rhyme for your reading pleasure
As we continue to pursue this curious dream
Of honing SpongeAPI into an intricate treasure
State of Sponge XIII was discordantly successful
We thank everyone for helping make number 13
Although the inner machinations may be stressful
The next (XIV) should be on June 10, 2017
Now enough of this rambling, let us go to the source
What better way to show how things are progressing
Than the path of development as visualised via Gource
This now concludes our introductory effervescing.
Development News
SpongeAPI 6 has been officially released! The new API does have a few breaking changes to the API, but mainly focuses on improvements of existing APIs while adding new features introduced by Minecraft 1.11.2. This brings the API up to speed with features and usability improvements for plugin developers.
With the release, this also means that now we have three branches of support, API 5.x for Minecraft 1.10.2, API 6 for Minecraft 1.11.2, and API 7, which currently targets Minecraft 1.11.2 with breaking changes to the API for even more usability improvements, including a major refactor with Causes.
Additions to the Sponge Development team have been made, please welcome @dualspiral as one of our newest Sponge Core Developers! His contributions and continued pursuit at improving the experience with Sponge and it’s internals with his plugin projects have shown great promise and he’s had great interest in helping improve the project in any way he can do so. We’ll be seeing some great things in the future, especially with Commands.
In other news, our development team has been working with several others as to updating various tools in the toolchain towards an eventual 1.12 release in the future with major improvements to SpongeForge’s compatibility with mods and other core mods.
Docs
HELP! Where are all the funky Pull Requests?
SpongeDocs wants you to help fill our chests
We still need help documenting Cause-Tracking
Docs for Inventory and Data are also lacking
If you think you can explain them, or give a walk-through
Talk to the editorial staff and show us what you can do.
We are still waiting to put to rest
Our SpongeDocs licensing Pull Request
Although progress has been seen
On both GitHub and Crowdin.
This was expected to take some time to complete…
Most contributors on GitHub have now agreed
To use the Creative Commons Share-Alike license
But there is the odd outstanding absence
Such as @mumfrey, @gratimax and @tyrannokapi.
We need everyone in to make this thing be.
Ore
Development on Ore has been proceeding smoothly. To kick things off, we’d like to present the official Ore Plugin Submission Guidelines. Please note that the below guidelines may be subject to change.
Welcome to the Ore submission guidelines. This document provides an outline of our expectations for both project and file submissions.
Remember that these are just guidelines and the Ore team, referred to as the “staff” throughout these guidelines, may choose to allow or disallow an action that is not explicitly listed here at our own discretion.
Projects
Submitted projects should meet the following expectations:
Name
Your project’s submitted name should not include a version, tagline, or other description. The name should be unique and original and must not have a name implying it is a Sponge project (e.g. SpongeWarp is not allowed, Cool Warps for Sponge is).
Main Documentation Page (Home)
This is the first page anyone sees when visiting your project. Information here should include a description of your project’s features. The following, if present in your plugin, should be documented on the main page if not documented elsewhere on the Ore project: commands, configuration, and permission nodes. Additionally, the below information must be documented on the main page if relevant:
External Connections
If your project utilizes a web API, phones home to collect data, or otherwise connects to a system external to the server it is running on, the presence of this feature as well as information on how to enable or disable it must be displayed prominently on the main page. If your project’s sole purpose involves utilizing an external system [such as a Sponge plugin that translates chat between languages], a configuration option to toggle making connections to that service is not required. If your plugin sends information (for example, plugin list or player data), the information collected must be listed on the main page.
Examples of systems that require documentation:
Statistics or usage information collection (‘metrics’)
Geolocation
Translation service
Web server that runs on the plugin, serving information to users
Server that runs on the plugin, listening to requests from other services
IRC/Discord/Telegram/WhatsApp bot or relay
Category
The category you choose should be accurate. Your project should use the narrowest category possible rather than any category that slightly applies. If no category appears accurate, the Miscellaneous category should be used.
Download Links
Ore provides, on each project page, a download button which will automatically choose the most recent release. If you wish to add additional download links, all links must point to files hosted on Ore. You may additionally link to unapproved file pages, not direct file links, on Ore but these links may not be the most prominently displayed links. Further, you may not attempt to circumvent any plugin warnings on Ore, including warnings that inform the user that a project has not yet been reviewed.
Monetization / Advertising
Submissions may not be sold, nor may additional features be unlockable with payment. Advertisements and other revenue generating links (e.g. adfly) are not permitted. The documentation may contain a link to a page to donate to the project maintainer or other contributors as thanks but that page may not offer additional features or other plugins/mods for sale.
“Cracked” / Offline-mode / online-mode=false Support
Projects that explicitly state they are designed for such uses are not allowed. Some projects, such as authentication systems, may have functionality that can be useful for servers regardless of the server’s use of Mojang authentication, but they may not promote this additional usage or be specifically designed for servers avoiding Mojang auth. Projects designed for proxies requiring online-mode=false are allowed, provided they are not written to facilitate circumvention of Minecraft account ownership.
EULA
We aim to comply entirely with the Mojang EULA. Any plugins, services, posts, and/or links suspected of violating the EULA may be removed at the discretion of the Sponge Staff or at the request of Mojang AB.
Forks
Forks are permitted, provided they meet all items in the below list. Staff have the final say in what constitutes an accepted fork.
Follow the license of the parent project appropriately.
Either:
Contain significant changes warranting the creation of a new project. This is to avoid “I changed the message colors in Plugin X and now I claim credit!”
Continue a plugin that has been abandoned, with proof the author has not been answering messages or has stated the project will no longer be updated.
Acknowledge or credit the past plugin and developers. Essentially, don’t claim it is a new plugin and exclusively your creation.
Files
Files submitted should meet the following expectations:
Obfuscation
A file that utilizes obfuscation will be denied unless it falls under the following exception:
NMS Obfuscation
This only applies for plugins which reference Minecraft or a Forge mod. Examples would be a plugin using Mixins or a plugin which doubles as a Forge mod (hybrid plugin). Provided that the only obfuscated references are to obfuscated source generated using ForgeGradle or VanillaGradle, the plugin is allowed to proceed through the review process.
Core Mods and Mixins: Modification of the Minecraft Base Code
Plugins and mods that use a system that modifies the Minecraft base code at runtime, (such as core mods and mixins) must disclose the edits that they make to the Minecraft code, and their reasoning for them. Sponge plugins should use the Sponge API where possible. Sponge implementations may implement technical restrictions to prevent such modifications from being applied by default. Files are not permitted to attempt to work around these restrictions, but can notify the user that enhanced functionality can be enabled via the Sponge provided configuration options.
External Connections (Web API, Phoning Home, etc.)
Many great features can be written by making calls to external systems. As well as being clearly documented in project descriptions, such functionality should be configurable and disabled by default. If your project’s sole purpose involves utilizing an external system (such as a Sponge plugin that translates chat between languages), connecting to that system does not need to be disableable. If your plugin sends information (e.g. a plugin list, player data, or map data) to external systems, the information collected must be listed on the main page (see above).
Execution of Downloaded Code
This is a security risk we will not tolerate. This includes downloading jar or class files, generation of bytecode from downloaded sources, and execution shell scripts.
Monetization / Advertising
All functionality present in your plugin should be usable without restriction, and can not require a license key to operate. External APIs, such as translation or geolocation services, that require payment for functionality can be allowed but must be discussed among staff prior to approval. Plugins may not be used to display advertisements.
Update Checking
Checking for updates should be performed using the provided Ore API. Your plugin may not link anywhere but Ore when directing users of your plugin to download new versions. Note that this update checking counts as an external connection, which must be documented and for which configuration must exist to disable it.
Privilege Granting
Plugins must not grant or revoke feature access to any particular user or group of users determined by the plugin developer. This includes the author granting themselves a special display name or letting themselves use a special command. Features, when applicable, should be locked behind permission nodes, rather than access being predetermined by the author. Commands for granting specific, pre-programmed users OP or permissions are not acceptable.
Plugin authors with existing Ore projects should ensure their projects meet the expectations written in the guidelines. If you have any questions or concerns about ensuring your project complies, feel free to leave a comment in reply to this thread or reach out to us on IRC.
Once Ore is officially launched, there will be significant changes to the “Plugins” Category on the Forums. The “Plugin Releases” subcategory will be placed into Reply-only mode one week after launch, then after a period of 3 months it will be locked as View-only and renamed to “Legacy Plugins”. The same timeline will also apply to the “WIP Plugin” subcategory, though this may be potentially merged into “Legacy Plugins” also. The “Sponge Plugin Competition” subcategory will remain, though future submissions will require the content to be hosted on Ore.
Keep an ear out too for the next Plugin Competition.It will be held to celebrate the launch of Ore, with several prizes to be won!
Sponge Community Server
Visit demo.spongepowered.org today! Join Us, we want more players to play
Help us test out this magnificent Sponge server that’s persistent
See the site of SOS XIII, in the Realistic Terrain scene
Discover nifty plugin features, fight or tame creatures
Build, earn and learn, Every player gets their turn
“Og say Sponge work real good. Trust Og. Og have hammer.”
The State Of Sponge XIV
Our next poriferous party shall be on June 10th, at 21:00 UTC
If you have any questions you’d like asked at SoS, you’re welcome to reply and add them to this thread.
You can join us at: Twitch
We hope to see you there!
If you’re disturbed by our generous use of rhyme
Maybe we’ll do something different, next time
