About Bloom

Bloom exists because Minecraft servers did not all move forward together. PvP networks still run 1.8; survival servers run the newest Paper; many developers write for both.

Why it exists

Writing a plugin that runs on Spigot 1.8 and on Paper 26 usually means one of two things: two codebases, or a tangle of version checks and reflection inside gameplay code. Bloom moves that work into one place. Your plugin talks to a single API; version adapters translate it for the server it is running on.

Architectural philosophy

• Small, stable interfaces in bloom-api; implementations behind them.
• Version differences live only in adapters, which are loaded by name after the server is identified.
• Plain Java 8 where the code must run on legacy servers, verified by running the tests on Java 8.
• No hidden behaviour: what Bloom starts, it stops, in a documented order.
• No large abstractions where Bukkit's own types are clear: menus take Bukkit players and item stacks.

Compatibility approach

Bloom distinguishes between versions it accepts, versions it compiled against, and versions it actually ran on. The compatibility page shows each separately, and Bloom refuses to start on a version without an adapter instead of guessing.

Contributing

Bloom is developed in the open on GitHub under the MIT license. Read CONTRIBUTING.md before opening a pull request: every change needs tests, and changes to shared Bukkit code must keep working on both adapter families. Report security problems privately as described in SECURITY.md.

Roadmap

1. Verify the legacy and modern adapters on real 1.7.10, 1.8.8, 1.21.11 and 26.3 servers.
2. Bloom Doctor: build-time checks for relocation, Java targets and cross-version API linkage.
3. First public release with artifacts on a Maven repository.
4. A standalone runtime plugin that several plugins can share.
5. More adapters (1.12, 1.16 to 1.20) and Folia scheduling, based on demand.