Announcement The future of Paper - Hard fork

After the release of the first builds for Minecraft 1.21.4, we are happy to share some even more exciting news with everyone. Following the successful rollout of our Mojang-mapped server in 1.20.5, we are taking a big next step for the project:

Hard fork from our upstream​

Since the project's inception, Paper has been built on top of Spigot, consistently staying up-to-date with features introduced to it. Today, Paper applies nearly 1600 additional patches with more than 130,000 lines of code over Spigot. As a result of such divergence, our strict policy to stay up-to-date with Spigot has been limiting the project, most noticeably with slower version updates since its updates to snapshots, pre-releases and release candidates are worked on behind closed doors.

Hardforking removes this unnecessary delay and sees Paper become its own independent project, streamlining development of the server and major missing API, such as our recent registry and item data component API. This does not mean that existing configs/API/behavior/etc. will be removed. Starting with 1.21.4, Paper will simply no longer be bound to Spigot's future changes, enabling us and the community to move forwards on our own terms.

While this may sound scary, we have bundled up some helpful disclaimers for each relevant user group down below. We are committed to making this process as smooth as possible for everyone. If any more questions arise, feel free to ask us on our Discord!

Server owners / administrators​

As a server owner/administrator, there will be no change initially. For now, both bukkit.yml and spigot.yml will continue to work how they always have. Plugins already running on the stable 1.21.4 builds as well as plugins compiling to older versions of Spigot will also continue to run. As the plugin API of Paper and Spigot slowly diverge, the only potential worry may be plugins trying to use Spigot features introduced after the hardfork.

We presume a large number of plugins to prefer Paper compatibility over Spigot already, given the current market share of the two projects. A huge upside for you is the considerably faster release speed of Paper during Minecraft releases, as mentioned prior. Post hardfork, we are able to update Paper to release-candidates, pre-releases and maybe even snapshots to get experimental builds out to everyone as early as possible.

Plugin developers​

Just like for server owners, there will be no initial change in the plugin API. Existing methods inherited from Spigot are maintained and will continue to work. This includes methods deprecated by us, like legacy text/chat color. However, we will no longer pull all new API added to Spigot after hardfork. To avoid accidentally calling such methods, we strongly suggest building your plugin against the Paper-API dependency. We are still open to manually pulling some new upstream API into Paper to ensure plugin developers do not lose out on functionality, but you should not rely on it.

Usage of server internals via paperweight-userdev will also continue to work as it has before, however, we recommend slowly preparing your plugin to run on a Mojang-mapped server with jar and reflection remapping disabled. This can be achieved with the -Dpaper.disablePluginRemapping=true startup flag. If you aren't already using paperweight-userdev despite using internal Vanilla classes directly, you should move towards it. If you are, you don't need to do anything else, as you can simply later remove the obfuscation step and will be compatible with the future change - only reflective calls need to be addressed. However, we will give you ample time to prepare for this and will continue to automatically remap plugins for a while. Once that happens, it will become much easier to support multiple versions with little internal changes, which the obfuscated mappings and arbitrary CraftBukkit package relocation currently prevent. The single set of standard mappings will also make debugging and code-sharing easier.

With the switch to Paper-API and later a Mojang-mapped server, your plugins may no longer run on Spigot. Paper's market share of 85-90% on recent versions (according to some of the largest plugins on bStats, including forks of Paper) should make it easy for you to support almost all of your users in the post-hardfork versions, even without being compatible with Spigot. Publishing plugins that require Paper can be done on numerous platforms, most notably Hangar and modrinth.

Moving our old version branches to a new repo​

Because we are merging in API/API-implementation source file history and the new branch will have an entirely unrelated git commit history to the previous branches, we will eventually delete all older version branches, everything from ver/1.8.8 up to ver/1.21.3. If you are in any way referencing them on our current repository, make sure to update their URL to:

https://github.com/PaperMC/Paper-archive

Our current compressed repo size is over 90MB - the new branch, despite having many many more commits, will be less than 35MB in packed size, meaning cloning the repository will become much faster once the old branches have been removed. On top of that, looking at the previous patch-file history will also be a lot easier thanks to cleaning up index and line changes from the history.

Paper contributors​

Hardfork affects contributions to Paper dramatically, most of it for the better. With hardfork, the Paper repository will receive a full restructure, moving the entire API and API-implementation straight as source into the repository. Contributions to these can now directly be made on the .java files, without the need to edit/rebuild patches. Changes to Mojang-owned sources will still be based on patches, but each Vanilla source file will be represented by a single, per-file patch. For large changes, like anti-xray and moonrise, Paper will also offer the old feature-based patch approach on top of the previously described layout, combining the best of both techniques, next to an updated decompiler (Vineflower) and mappings set (Parchment).

In order to preserve history, we have merged multiple git trees, including our full patch-file history, and those patches applied into real commits over the existing Spigot history. Older states containing decompiled Vanilla source files have been filtered. The history change unfortunately means that all open PRs will have to be closed later, and they cannot be force-pushed to target the new branch either. Please do not reopen PRs until we provide more detailed information on how to semi-automatically update old pull requests and have given the go-ahead for new ones.

Paper fork developers​

The main change you will have to deal with is the updated decompiler and mappings. We will provide you with more information once our initial update process is finished. New versions of Paperweight patcher will be published to be compatible with our new repository structure. For now, make sure you change upstream targets of 1.21.3 and older to the new archive repository.

Next steps/rough timeline​

It's hard to give an exact timeline, but you will be able to follow the rough progress of our hard fork process in the following GitHub issue: https://github.com/PaperMC/Paper/issues/11735

1. We will spend the following weeks updating the repository by changing the patch structure and fixing endless patch conflicts from the updated decompiler and new set of local/parameter mappings.
2. Once that is done, we will push these builds as experimental builds to ensure we didn't break any backwards compatibility or introduced any new issues.
3. Once we have finished our tooling around forks and userdev, we will post an announcement on how to update forks and notify Paper contributors on how to properly update their pull requests to the new main branch.

At some point down the line on new Minecraft releases, you can expect API and preliminary builds to be published even before the full Minecraft release day. Eventually, we will start cleaning up and automatically migrating the different configs, and slowly remove long-disfunctional deprecated API, but our focus remains to make these transitions as smooth and graceful as possible.

---

TL;DR​

This change allows us to work on snapshots, and to more freely work on major missing API. Contributions to Paper become a lot easier, and plugin development will become easier as well, both regarding API and server internals!

Server admins: No action needed, but you might no longer be able to go back to Spigot starting with 1.21.4.
Plugin developers: No immediate action needed, but you should compile against Paper-API starting with 1.21.4.
Paper contributors: You will have to redo your PRs, but we will tell you more about that later and provide you with useful scripts and tools.
Forks/server hosts: Migrate any use of the old version branches (e.g. ver/1.8.8, ver/1.21.1; everything below 1.21.4) to the new archive repository.

Thank you for making the Paper organization into what it has become today, we're grateful that so many people choose to use our software! Focusing on preparations for this process took a toll on Paper pull requests and Hangar activity, but we'll be able to churn through these much faster afterwards!

 

alternatives designed for paper dont work like original ones. Slimefun alternatives Such as itemedit doesn't have Industry related things.

I did also say fork in the message you quoted. That's also a possibility, for if a plugin chooses to only support a couple percent of their users, abandoning 95% of them.

i am super scared about paper's future, what if bukkit/spigot compatblity breaks?

I do not know what to tell you, as you appear unwilling to accept any possibility but catastrophe.

 

of course i am unwilling to accept any possibility but catastrophe. there is no better alternatives for slimefun. No One will try to rewrite Slimefun IV and some of the alternatives use commands or configs(which are vulnerable) instead of Java Code. of course i'm scared of it. sorry for off-topic by the way.

 

I don’t know why your personal choice of software to use becomes a responsibility of PaperMC. Seems to be a very self-centered viewpoint. Hard fork is generally a good thing for Paper itself. Either embrace it or be left in forgotten history. The world moves on without you or me - that's just how things are.

 

maybe i will consider embracing it... i have no choice, but to say goodbye to our Spigot Plugin Development.

 

I mean, the maintainer of Slimefun also indicated that from 1.21 onward, they will drop Spigot support in favor of Paper, so I honestly am not sure where all the fear comes from. Did you perhaps missed their announcement?

 

oh, thank god it's dropping support for spigot now. ok, now i understand. i have to accept the hardfork. and maybe, adapt to new modern API. i wasn't aware about the announcement because i didnt have a discord account.

 

is there a chance that Spigot API get replaced with new api and Dropped in the future when Paper Plugin API is complete?

 

No API that isn't already marked as deprecated for removal will be removed

 

well, seems that no matter what, we must Move Away from SpigotMC, And adapt to New Modern API and Forum. This Is Not an Temporary Moving from Spigot API, SpigotMC Forum, Reobfuscated Mapping Server, to Paper-API, PaperMC Forum, hangar&Modrinth, Mojang Mapping, This is an Exodus from Spigot API, Spigot Forum, The Destination is PaperMC, This Is An Exodus From Spigot, Where we accept the hardfork and Move on.

Your Hardfork was bit scary, but it was Liberating from the strict rules of SpigotMC.

Hope we see the Pre Release Versions!

 

Hello
I've been following this closely and have read the entire thread, including the responses from the Paper developers. I understand the purpose of this hardfork, but I agree with some other admins who are concerned because my server relies on numerous plugins to deliver its content.
So I submitted the question to a few developers to anticipate the impact this will have on my server and to see which plugins won't follow Paper when it decouples from Spigot. A large number of them replied that they won't support two APIs at the same time and that they will stick with Spigot. Furthermore, supporting only Paper would prohibit them from using Spigot site, which remains the most popular and well-known site for distributing their plugins. Despite the fact that Paper is now much more widely used than Spigot (63% vs. 16%), they prefer to continue supporting Spigot...

In short, all this is to say that our concerns remain valid at this time, and if the Paper hardfork breaks compatibility with the Spigot API in future, it's undeniable that many servers will find it very difficult to continue updating their plugins. Especially those that use a lot of them, including some that don't have an equivalent.
For us, the question to ask is whether it's more viable for our servers to switch back to Spigot while there's still time, or whether we take the risk of following Paper. It's a difficult gamble, fraught with uncertainty; not to mention the servers that have no choice but to remain on Paper due to its high resource consumption.

Anyway, thanks for your great work on Paper

 

We understand your concerns that some of the plugins you're currently using might no longer work on Paper in the future because the developers will only support Spigot. However, we know of many plugins that will either keep supporting both Spigot and Paper or outright only support Paper in the future, such as WorldEdit, WorldGuard, EssentialsX, and Geyser. Furthermore, for modern versions, there is an even larger divide between Spigot and Paper. For example, for 1.21.4, the amount of servers using Paper is >95%, so we're confident that many plugins will keep supporting Paper. Of course there might be some developers that will only support Spigot, but we expect the community to be able to provide forks or alternatives for these plugins for Paper.