This parameter is not used for the vast majority of task use cases and just serves as extra useless boilerplate code, especially for closure-based tasks.
This use case can be replaced using Server->getTick() in the cases where it matters.
This is now self-maintaining and doesn't rely on the async pool to wipe its ass on task completion. Instead, the garbage collector will cause thread-local data to be automatically released when the async task is garbage-collected on the main thread.
This brings two plugin-breaking changes: AsyncTask->onCompletion() and AsyncTask->onProgressUpdate() no longer accept Server parameters.
This now allows for the functionality of AsyncPool and AsyncTask to be tested outside of a Server.
I am eating my own words this once, because having the tester plugin as a separate repository makes no sense - it is just added barriers to writing proper tests with no actual benefit. Since the tester plugin is specifically intended for CI, it doesn't make sense for it to be in its own module.
This may raise a few eyebrows.
Does this mean that all the things that were planned for API 3.0.0 are done?
Not at all. The plans laid out in December 2016 for API 3.0.0 were far too ambitious, and as a result the ALPHA series dragged out forever (18 months now). This is a break away from those plans, to bring development and release flow back to some sort of sanity.
Does this mean that my plugins will stop breaking all the time now?
No, it does not! Development isn't going to stop, although breaking changes will be confined only to major API releases. It's anticipated that the major API version will be bumped as nearly as often as the ALPHA version was during the last 18 months. The reason for this return to 3.0.0 is to allow us to fine-tune our release flow so that plugin developers can get advantage of newer, non-breaking API features without having to bump the API in a breaking way.
What are the criteria for the API versions now?
- Major: This will be bumped for breaking changes, changes which will break plugins. it's expected that we'll roll out new major versions regularly.
- Minor: This will be bumped when non-breaking feature additions are made, such that API 3.0.0 plugins would still load on 3.1.0. However, plugins requiring 3.1.0 will not run on 3.0.0.
- Patch: This will be bumped for bugfix updates. Plugins requiring 3.0.0 will work on 3.0.1, but not vice versa.
TL;DR: This insanity has gone on far too long.
This features a near-total rewrite of PluginLoaders and some code associated with them.
Highlights:
- PluginManager->registerInterface() does not return anything, and now accepts a PluginLoader instance instead of a string.
- PluginLoader itself is drastically simplified. getPluginFilters(), enablePlugin() and disablePlugin() are now removed. loadPlugin() responsibilities are now solely confined to doing whatever is necessary to make the plugin's classes visible by the server, and does not emit log messages or check for data directories.
- PluginBase->init() and PluginBase->isInitialized() have been removed.
- Plugin interface now declares a signature for the constructor which implementations must comply with.
- Plugin interface now declares setEnabled().
