Let the Festivities Commence, for the Sponge Project is a Year Old! Huzzah!
Sponge Docs Pop Quiz #7
Many things have changed since the inception of Sponge. It has grown in many directions that could never have been predicted at the beginning, and absorbed things in a way that only Sponge can. Let us put some small issues through the wringer and see what comes out.
Multilingual Sponge Forums: would it make sense?
Rather than encourage the spread of unofficial non-english Sponge support forums & videos, would it make more sense to have Sub-forums here, or via some other collective arrangement?
Are there any good server use-cases for Java 7, versus Java 8?
As Sponge is transitioning to Java 8, we are interested to know if anyone will get left behind for reasons other than apathy. Who still needs Java 7 (or Java 6), and why?
Is there a better way of handling API / Implementation versioning for plugins?
Some have suggested that plugins declare the version of SpongeAPI they were built against. Should we introduce names for API major versions? There has also been no evolution of the Implementation version since Inspired Wallaroo either, just Build numbers; what should we do?
Relax, have a drink, enjoy some Sponge Cake, and chill to the rhythm of development. If you missed Quiz #6, you can still find it here. Thanks for sharing this cosmic wavelength and be sure to check out the same harmonics next week. Over and Under and Out.
Multilingual Sponge Forums: would it make sense?
I don’t believe so. The purpose of these forums are to provide support for the platform that we’ve created. Providing that support based off of back-and-forth Google translations probably isn’t the best route for us to go.
Obviously, there are a couple caveats to what I said, namely: Couldn’t you just have people on staff who are bilingual provide support for that group? To which I respond, Not really.
That would put quite a bit of weight for support onto a single/few person(s) - I believe it’s best to just stick with English, for now.
Are there any good server use-cases for Java 7, versus Java 8?
At-gun-point system operator decision making.
Is there a better way of handling API / Implementation versioning for plugins?
This will become less of an issue, the more complete the Sponge API becomes. The entire point of an API is to allow interfacing with a platform with minimal breaking. Meaning that the plugin will work from one implementation to the other, because the API is consistent. This is obviously more of a concern during active development because things are constantly shifting.
However, I do not believe that an intricate versioning system is necessary because of issues that arise during this phase. It’ll make things more complicated in the future for an issue that won’t exist.
I would recommend people use translation services to go to and from English. Google Chrome can translate any page automatically.
Doubt it. There could be some servers that run other Java applications that fail on Java 8 but Java is very backward-compatible so that would be unlikely.
semver. That’s the answer to any versioning questions.
So the version format of major.minor.patch following semver would mean that a plugin built for a major version will work for all implementations for that major version.
Lets say SpongeAPI 3 is released. A plugin for API 3 would be binary compatible with 3.0.0, 3.1.4, 3.8.9, 3.14.5 etc but is not guaranteed to be compatible with 2.1.0 or 4.2.1 etc.
Some plugins may be dependent on say 3.2+ meaning it relies on some new feature introduced in 3.2.0.
I hope the leaders will draft a plan for the versioning scheme so we are all on the same line.
1. Multilingual Sponge Forums: would it make sense?
I think if we are going multilingual, then a single thread per language should be enough. This implies that we only support/offer languages the team is able to understand. This should be at least german and french, maybe spanish (do we have spanish speaking staff?).
I’m not sure we should go down this Route. The idea of just posting bilingual (if english only seems impossible) is nice. Would choose this Option, as saladoc did too.
2. Are there any good server use-cases for Java 7, versus Java 8?
Don’t think so. Only reason one should not use Java 8 is when a hosting company refuses to update to 8.
There are some very old OSX versions which support Java6 only, but this should be a problem for clients, not server.
3. Is there a better way of handling API / Implementation versioning for plugins?
I’d like to have names vor every major API version and every major Implementation release. I call SpongeForge Alpha and Beta a major version and after that every version supporting a new major MC version (1.8, 1.9…). This isn’t important, but i think having a nice name for our releases would fit and show our dedication (and tbh naming is somewhat cute and cool ).
On top of that i’d like to see semver. Maybe not for alpha and beta (build # suffices) but for release versions.
1. Multilingual Sponge Forums: would it make sense?
No. As a community, we are tolerant enough to not ridicule people if their english is imperfect. Even if people lack the words, they can just post first their english translation and then their original text in their native language in the same thread. That way, english speaking users can try to help and if someone who speaks their language reads it, they may even answer in it (or better - bilingual. That way everyone reading it may profit). It happened before that someone not too confident in english found someone to help him in their native tongue. I see no reason why that should be restricted to specific forums.
2. Are there any good server use-cases for Java 7, versus Java 8?
I’m not aware of any.
3. Is there a better way of handling API / Implementation versioning for plugins?
I’m with @Tzk here. Names for major releases (but alliterations only - Leaking Leprachaun, Jinxed Jabberwocky, Dignified Diplodocus, …) and for everything else, semantic versioning for release versions.
Only one: if the host has a terrible support team, which does happen.
I’m not sure on this one, since Sponge is constantly evolving. Any commit can add something new, and it wouldn’t be a good idea to change a version number every commit. I’d probably use a format that’s a combination of semver and the Minecraft version.
).