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:
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!
 
i actually read the post, i know what's going on. i know you guys want to not depend on Spigot/CraftBukkit Updates to make the update faster.
i still oppose this. looks terrible idea to me. if paper go independent on spigot, and if you unable to go back to spigot, and the plugins using paper-api cannot run on spigot, it's not counted as fork anymore. it's scary.
 
We are still a fork of spigot in terms of what a fork actually is, we are, however, not intending to keep aligned with our quasi closed upstream project, and have decided that we would much rather place ourselves in a position where we can work on stuff without having to worry about conflicts arising when they add features we have half a decade later.

the plugins using paper-api cannot run on spigot

If you use API specific to paper API, it will not work on spigot; That has literally always been the case; long term, we will diverge, however, such is how actual forks go.
 
i actually read the post, i know what's going on. i know you guys want to not depend on Spigot/CraftBukkit Updates to make the update faster.
i still oppose this. looks terrible idea to me. if paper go independent on spigot, and if you unable to go back to spigot, and the plugins using paper-api cannot run on spigot, it's not counted as fork anymore. it's scary.
Considering 90 to 95 percent of modern servers run Paper or derivatives, it's not scary at all! It's liberating.

I'm aware of dozens and dozens of plugins planning to just use paper-api, and one plugin that wants to stay on spigot.
 
no, it's scary to me. it's not liberating to me. what if Citizens 2 Uses New API/Methods/Enums Introduced By Spigot on their update? besides that, Citizens use Relocation.
Considering 90 to 95 percent of modern servers run Paper or derivatives, it's not scary at all! It's liberating.

I'm aware of dozens and dozens of plugins planning to just use paper-api, and one plugin that wants to stay on spigot.
 
no, it's scary to me. it's not liberating to me. what if Citizens 2 Uses New API/Methods/Enums Introduced By Spigot on their update? besides that, Citizens use Relocation.
Most plugins will probably aim for working on paper considering how many servers run it. And if a dev for some reason would rather have their plugin work on a minority of servers instead of the majority and the plugin is somewhat popular there will probably be some fork made to target paper-api. I don't know about Citizens though i would think they will try to make their plugin work for both paper and spigot?
 
I am a bit inclined to oppose this decision.
I don't know what content was included in the bstats data that the developers reviewed when making this decision, so it seems that they may have some misunderstandings about the current situation of Paper.

For many server owners, the greatest significance of using Paper is "high performance" and compatibility with Spigot, allowing them to enjoy Spigot's long-standing plugin community while also having a modern performance server software. Even for many developers, why do I have to migrate downstream and manually narrow down the compatibility range of my plugins if there is no need for me to use the PaperAPI?

That is to say, running Paper servers has a huge market share, but it does not necessarily mean that there is a strong willingness to develop Paper plugins. In fact, I am willing to post the startup logs of my server. Let's take a look at what plugins my server (a survival oriented server that has not been modified much) consists of:

[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Paper plugins (3):
- BKCommonLib (1.21.4-v1-SNAPSHOT), CrazyCrates (3.4.9), PrefiX (7.3)
[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Bukkit plugins (71):
- AdvancedCleaner (1.4), AnimatedScoreboard (0.3.5), AuthMe (5.6.0-beta2-b2453), AuthOp (0.1), BetterRTP (3.6.12), CMILib (1.5.2.8), Chat2QQ (1.6), CheckpointX (3.0.7), Chunky (1.4.10), Citizens (2.0.37-SNAPSHOT (build 3691)), CommandToItem (${version}), CommonEditLib (1.2.1), CraftEnhance (2.5.6.3.3), CurveBuilding (0.6.2), DecentHolograms (2.8.12), DeluxeMenus (1.14.1-DEV-183), DisplayEntityEditor (1.0.15), Essentials (2.21.0-dev+93-3a6fdd9), EssentialsChat (2.21.0-dev+93-3a6fdd9), ExcellentEnchants (4.3.3), ExtraContexts (2.0-SNAPSHOT), GSit (1.12.1), ImageFrame (1.7.13.0), ItemEdit (3.5.5), ItemTag (3.5.1), Link2QQ (1.2), LuckPerms (5.4.131), MechanicsCore (4.0.1), MiniMOTD (2.1.0), MiraiMC (1.8-rc1), MoarBows (2.6), MobArena (0.108), MobsToEggs (1.7.14), Multiverse-Core (4.3.13), Multiverse-Portals (4.2.3), NexEngine (2.2.12), NoChatReports (2.3.0), ODailyQuests (2.3.0-SNAPSHOT-10), PlaceholderAPI (2.11.6), PlayerAuctions (1.28.1), PlayerParticles (8.8), ProtocolLib (5.4.0-SNAPSHOT-739), Quests (3.15.2-b216e2b), QuickShop-Hikari (6.2.0.7), RealisticSeasons (11.6.3), RedstoneMutex (1.0-SNAPSHOT), Residence (5.1.6.4), ScriptBlockPlus (2.3.2), Sentinel (2.9.1-SNAPSHOT (build 523)), SetSpawn (4.8), SkinsRestorer (15.5.1), SpeedRoads (1.0.1), StartupCommands (0.0.6), TAB (5.0.3), TerraformGenerator (18.0.0), TianyuQQBinder (1.0), Train_Carts (1.21.4-v1-SNAPSHOT), Traincarts2Dynmap (1.0), Vault (1.7.3-b131), VeinMiner (2.2.6), ViaBackwards (5.2.2-SNAPSHOT), ViaVersion (5.2.2-SNAPSHOT), WeaponMechanics (4.0.2), WeaveCustomSchedule (1.0), WeaveLumenController (1.0), WorldEdit (7.3.10-beta-01+cb9fd58), WorldEditSelectionVisualizer (2.1.6), nightcore (2.7.3), packetevents (2.7.0), pvparena (1.15.4-SNAPSHOT), qsaddon-list (6.1.0.2)

TL, DR: 3 Paper plugins, 71 Bukkit (Spigot) plugins.

There are many plugins here, such as Residence, Authme, DecentHolograms, DeluxeMenus and Citizens, which are also used on many servers, but they are not the Paper version and currently do not seem interested in updating to Paper.

I don't know what kind of confidence I need to have in this situation to make me believe that I should continue to follow up on the progress of Paper updates.

And, This decision will undoubtedly divide the communities of Spigot and Paper in the long run, forcing all plugin developers to face a "choice between two" situation. As far as the current situation is concerned, I cannot consider this a wise decision.
 
I am a bit inclined to oppose this decision.
I don't know what content was included in the bstats data that the developers reviewed when making this decision, so it seems that they may have some misunderstandings about the current situation of Paper.

For many server owners, the greatest significance of using Paper is "high performance" and compatibility with Spigot, allowing them to enjoy Spigot's long-standing plugin community while also having a modern performance server software. Even for many developers, why do I have to migrate downstream and manually narrow down the compatibility range of my plugins if there is no need for me to use the PaperAPI?

That is to say, running Paper servers has a huge market share, but it does not necessarily mean that there is a strong willingness to develop Paper plugins. In fact, I am willing to post the startup logs of my server. Let's take a look at what plugins my server (a survival oriented server that has not been modified much) consists of:

[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Paper plugins (3):
- BKCommonLib (1.21.4-v1-SNAPSHOT), CrazyCrates (3.4.9), PrefiX (7.3)
[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Bukkit plugins (71):
- AdvancedCleaner (1.4), AnimatedScoreboard (0.3.5), AuthMe (5.6.0-beta2-b2453), AuthOp (0.1), BetterRTP (3.6.12), CMILib (1.5.2.8), Chat2QQ (1.6), CheckpointX (3.0.7), Chunky (1.4.10), Citizens (2.0.37-SNAPSHOT (build 3691)), CommandToItem (${version}), CommonEditLib (1.2.1), CraftEnhance (2.5.6.3.3), CurveBuilding (0.6.2), DecentHolograms (2.8.12), DeluxeMenus (1.14.1-DEV-183), DisplayEntityEditor (1.0.15), Essentials (2.21.0-dev+93-3a6fdd9), EssentialsChat (2.21.0-dev+93-3a6fdd9), ExcellentEnchants (4.3.3), ExtraContexts (2.0-SNAPSHOT), GSit (1.12.1), ImageFrame (1.7.13.0), ItemEdit (3.5.5), ItemTag (3.5.1), Link2QQ (1.2), LuckPerms (5.4.131), MechanicsCore (4.0.1), MiniMOTD (2.1.0), MiraiMC (1.8-rc1), MoarBows (2.6), MobArena (0.108), MobsToEggs (1.7.14), Multiverse-Core (4.3.13), Multiverse-Portals (4.2.3), NexEngine (2.2.12), NoChatReports (2.3.0), ODailyQuests (2.3.0-SNAPSHOT-10), PlaceholderAPI (2.11.6), PlayerAuctions (1.28.1), PlayerParticles (8.8), ProtocolLib (5.4.0-SNAPSHOT-739), Quests (3.15.2-b216e2b), QuickShop-Hikari (6.2.0.7), RealisticSeasons (11.6.3), RedstoneMutex (1.0-SNAPSHOT), Residence (5.1.6.4), ScriptBlockPlus (2.3.2), Sentinel (2.9.1-SNAPSHOT (build 523)), SetSpawn (4.8), SkinsRestorer (15.5.1), SpeedRoads (1.0.1), StartupCommands (0.0.6), TAB (5.0.3), TerraformGenerator (18.0.0), TianyuQQBinder (1.0), Train_Carts (1.21.4-v1-SNAPSHOT), Traincarts2Dynmap (1.0), Vault (1.7.3-b131), VeinMiner (2.2.6), ViaBackwards (5.2.2-SNAPSHOT), ViaVersion (5.2.2-SNAPSHOT), WeaponMechanics (4.0.2), WeaveCustomSchedule (1.0), WeaveLumenController (1.0), WorldEdit (7.3.10-beta-01+cb9fd58), WorldEditSelectionVisualizer (2.1.6), nightcore (2.7.3), packetevents (2.7.0), pvparena (1.15.4-SNAPSHOT), qsaddon-list (6.1.0.2)

TL, DR: 3 Paper plugins, 71 Bukkit (Spigot) plugins.

There are many plugins here, such as Residence, Authme, DecentHolograms, DeluxeMenus and Citizens, which are also used on many servers, but they are not the Paper version and currently do not seem interested in updating to Paper.

I don't know what kind of confidence I need to have in this situation to make me believe that I should continue to follow up on the progress of Paper updates.

And, This decision will undoubtedly divide the communities of Spigot and Paper in the long run, forcing all plugin developers to face a "choice between two" situation. As far as the current situation is concerned, I cannot consider this a wise decision.
agreed. i oppose this. we hate to face choice between 2. see? it's scary.
 
"Paper plugin" is sort of bad branding on our side, it does not mean that any of the other plugins are not using Paper API, it's simply a separate (optional!) plugin loader with more features. Most of your plugins already use some form of Paper API or even strongly recommend using Paper.
why do I have to migrate downstream and manually narrow down the compatibility range of my plugins if there is no need for me to use the PaperAPI?
Hence this is a bit of a misnomer; not using Paper already limits a lot of your plugins' functionality. I can guarantee you that both devs and Paper users won't get the short end of the stick once the two platforms diverge further. I understand that such change can be scary, but you really have nothing to worry about, and there's hardly a difficult choice to be made here. Either you add simple compatibility measures if you really need to support those remaining few %, or you simply swap a dependency only for new versions going forward
 
Afaik paper plugins are also currently in the process of being rebranded to Lifecycle plugins which is a more accurate term. Your plugin does not need to be a paper/Lifecycle plugin to work on paper infact we recommend people do not use this plugin loader unless you need the Features it provides
 
For many server owners, the greatest significance of using Paper is "high performance" and compatibility with Spigot, allowing them to enjoy Spigot's long-standing plugin community while also having a modern performance server software. Even for many developers, why do I have to migrate downstream and manually narrow down the compatibility range of my plugins if there is no need for me to use the PaperAPI?

We're not going to break existing APIs for some sizable period of time; the only immediate difference is us not merging new APIs, but most of the side effects of this have been navigated by plugin developers for years, given that they're often expected or desire to support multiple versions of the software. We trust that the developers who are willing are smart enough to figure out how they'd want to support two platforms should they desire. This is especially true when plugins are increasingly having to rely on fragile operations to take advantage of Mojang's infra improvements in the server.

That is to say, running Paper servers has a huge market share, but it does not necessarily mean that there is a strong willingness to develop Paper plugins. In fact, I am willing to post the startup logs of my server. Let's take a look at what plugins my server (a survival oriented server that has not been modified much) consists of:

[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Paper plugins (3):
- BKCommonLib (1.21.4-v1-SNAPSHOT), CrazyCrates (3.4.9), PrefiX (7.3)
[12:19:32] [ServerMain/INFO]: [PluginInitializerManager] Bukkit plugins (71):
- AdvancedCleaner (1.4), AnimatedScoreboard (0.3.5), AuthMe (5.6.0-beta2-b2453), AuthOp (0.1), BetterRTP (3.6.12), CMILib (1.5.2.8), Chat2QQ (1.6), CheckpointX (3.0.7), Chunky (1.4.10), Citizens (2.0.37-SNAPSHOT (build 3691)), CommandToItem (${version}), CommonEditLib (1.2.1), CraftEnhance (2.5.6.3.3), CurveBuilding (0.6.2), DecentHolograms (2.8.12), DeluxeMenus (1.14.1-DEV-183), DisplayEntityEditor (1.0.15), Essentials (2.21.0-dev+93-3a6fdd9), EssentialsChat (2.21.0-dev+93-3a6fdd9), ExcellentEnchants (4.3.3), ExtraContexts (2.0-SNAPSHOT), GSit (1.12.1), ImageFrame (1.7.13.0), ItemEdit (3.5.5), ItemTag (3.5.1), Link2QQ (1.2), LuckPerms (5.4.131), MechanicsCore (4.0.1), MiniMOTD (2.1.0), MiraiMC (1.8-rc1), MoarBows (2.6), MobArena (0.108), MobsToEggs (1.7.14), Multiverse-Core (4.3.13), Multiverse-Portals (4.2.3), NexEngine (2.2.12), NoChatReports (2.3.0), ODailyQuests (2.3.0-SNAPSHOT-10), PlaceholderAPI (2.11.6), PlayerAuctions (1.28.1), PlayerParticles (8.8), ProtocolLib (5.4.0-SNAPSHOT-739), Quests (3.15.2-b216e2b), QuickShop-Hikari (6.2.0.7), RealisticSeasons (11.6.3), RedstoneMutex (1.0-SNAPSHOT), Residence (5.1.6.4), ScriptBlockPlus (2.3.2), Sentinel (2.9.1-SNAPSHOT (build 523)), SetSpawn (4.8), SkinsRestorer (15.5.1), SpeedRoads (1.0.1), StartupCommands (0.0.6), TAB (5.0.3), TerraformGenerator (18.0.0), TianyuQQBinder (1.0), Train_Carts (1.21.4-v1-SNAPSHOT), Traincarts2Dynmap (1.0), Vault (1.7.3-b131), VeinMiner (2.2.6), ViaBackwards (5.2.2-SNAPSHOT), ViaVersion (5.2.2-SNAPSHOT), WeaponMechanics (4.0.2), WeaveCustomSchedule (1.0), WeaveLumenController (1.0), WorldEdit (7.3.10-beta-01+cb9fd58), WorldEditSelectionVisualizer (2.1.6), nightcore (2.7.3), packetevents (2.7.0), pvparena (1.15.4-SNAPSHOT), qsaddon-list (6.1.0.2)

TL, DR: 3 Paper plugins, 71 Bukkit (Spigot) plugins.

This is a misnomer; paper plugins are more just "advanced bootstrapper lifecycle plugins", offering access for plugins to bootstrap earlier and perform various operations, such as injecting entries into the servers' registry, something which is going to become increasingly important over the next (and past) few years as mojang is data driving the server software. Paper already has native support for plugins to register custom enchantments, painting variants, damage types, and more over the next few years.

There is no requirement for plugins to adapt to this system; in fact, we actively discourage people from using this system unless they need to use it for something. The reality is that most plugins do not need to opt into using the early bootstrapper stuff, but it's there for the plugins that want to.

I don't know what kind of confidence I need to have in this situation to make me believe that I should continue to follow up on the progress of Paper updates.

And, This decision will undoubtedly divide the communities of Spigot and Paper in the long run, forcing all plugin developers to face a "choice between two" situation. As far as the current situation is concerned, I cannot consider this a wise decision.
Spigot hasn't cared to interact with the community outside of its little cubby hole for well over a decade now, and the last noticeable interaction we had with the project was an "if you start sending us all your patches and kill off Paper, I might let you join the spigot team". The only real community overlap I've seen is active paper developers going over to Spigot to try to collaborate on aspects like API design that impact us, such as the Item/BlockType APIs, which are much more in line with our original vision we had 10 years ago. The only reach-out we ever got from there these days is the odd contributor who wants our input on something they worked on.

--

We have so many patches over Spigot that we weren't able to explore our patches folder on GitHub for the past year, and the paralysis of "but, spigot might expose API for that" often made us stall working on or merging PRs for such features, such as the work we'd started to do on breaking down Material in preparation for stuff to be registry driven (as well as the well-needed separation from that broken API concept), something Spigot finally accepted needed to happen, almost 10 years after core project leaders in Paper identified the need for this.


Mojang's recent changes are also "fun" in that releases are more frequent and much heavier on the workload in order to rewrite parts of the game, especially when dealing with the unstable output provided by upstreams' tooling which frequently caused conflicts due to them using a much older decompiler which produced more unstable and less 'unrefined' output, we have a fraction of the decompile fixes that spigot needs with the entire source subtree decompiled vs the partial decompile that spigot performs. Thanks to taking advantage of and collaborating with projects within the community, our source tree is much nicer to work with.

The nature of Mojang's new release cycle also allows them to release new features and iterate on them. Rather than the ping-pong, pong-pong, pong we'd get where you'd deal with a substantially large update followed up by what are often smaller fixes, the releases are now more ping-pong, ping-pong. This means that we're no longer dealing with one or two substantial updates a year combined with a few quick ones but multiple sizable releases a year. Part of the reason we've been able to manage this thus far is more a set of happenchances; we can't start to work on anything until our quasi-closed-source upstream performs a release, by luck, the timezones generally mean that this is an early afternoon for us Europeans, assuming he doesn't hold a release hostage, we can generally preplan to some degree for people to be around to start, however, it's only through the fact that our team we've managed to build is crazily committed to developing this software for the community and is willing to pull off the crazy hours and work around the clock, which is honestly so unsustainable I'm surprised that we've managed to pull it off for as long as we have.

--

It's also worth remembering that one of the first changes Mojang did on this release cycle was rewriting the entirety of how ItemStacks are represented, migrating from "just a blob of NBT" into a much more structured and defined manner of representing this data, with items now defining their data using prototypes rather than sporadically hardcoded behaviour across the codebase; These changes were probably one of the more notable divergences from Spigot we've had here;

1) The ItemMeta API that they're so insistent on refusing to migrate away from is broken and fails to represent how items work in the game, i.e. you cannot query attributes about a food item in vanilla in their API; only items with that component overridden by plugins, manually; That means that you can't query components which are actually on the Item itself and would thus need to use internals or hardcoding, to perform such operations.

2) Spigot opted for compatibility of legacy API behaviour in a manner that transforms "I want to hide the attributes on this item" into "I want to disable all of the default attributes on this item, turning all of my tools into performing worse than wooden tier tools", rather than actually addressing the fact that ItemStacks are a bit less malleable on this front. In terms of working with the community rather than sticking in our corner, we've been able to highlight to Mojang that many members and we dislike this underlying change as it creates a bunch of issues; as for what Mojang will do with that, we're yet to see, but, at least we know they know the discontent of the bundling of some of this data on their components.

It's worth noting that we already saw the signs on the wall and had started work on a Data Component API when Mojang released this change, a welcomed happy surprise that we were able to adopt directly to cater towards that underlying data representation relatively easily;

And that's before you get into API that Spigot generally refused to support for the better part of a decade, i.e. the Biome API only just got support for custom biomes, something we've had primitive support for in Paper for years, but even as much as we wanted to, couldn't work on replacing it as, at first, we'd have to break API compatibility; Then, after a few years, they finally accepted that it needed to happen, in which, we where then stuck on waiting for them to decide if and how they're going to do it; Do they go the route that allows us to deprecate the older API and move forward with the new, and properly expose the underlying data represented by Biomes, or, do they go the route that keeps legacy plugins work for a millennium and fail to expose any modern information about Biomes to plugins. They, of course, opted for the latter.

--

As much as I'd love to say, "Paper is forever," one day, I and the many others I interact with on this project daily will one day get too busy and have to move on. For that, we will need to be able to onboard new developers and find people who are able and willing to replace myself and other team members as the time arises. There are many people out there who fit that bill, but the project's stalemate was just not conducive to that.

The hard fork isn't something new; it has been discussed with the community and other developers for years. Mojang's new release cycles, our desire to work on supporting many of the new things Mojang is increasingly offering in the game, and dealing with the fact that we were struggling to onboard new developers means that we hit our "now or never"; and now, rather than worrying about how we might have to wind this project down over the next 5 years, We're more focused on ensuring that the next 5 years is spent on preparing for the next 5 years after that. The hard fork was pretty essential to the life of this project, and we hope that many are willing to join the ride with us over the next many years, but, it is ultimately your server.

--
NB: apologies that this got kinda rambly
 
  • Like
Reactions: LoJoSho
We're not going to break existing APIs for some sizable period of time; the only immediate difference is us not merging new APIs, but most of the side effects of this have been navigated by plugin developers for years, given that they're often expected or desire to support multiple versions of the software. We trust that the developers who are willing are smart enough to figure out how they'd want to support two platforms should they desire. This is especially true when plugins are increasingly having to rely on fragile operations to take advantage of Mojang's infra improvements in the server.



This is a misnomer; paper plugins are more just "advanced bootstrapper lifecycle plugins", offering access for plugins to bootstrap earlier and perform various operations, such as injecting entries into the servers' registry, something which is going to become increasingly important over the next (and past) few years as mojang is data driving the server software. Paper already has native support for plugins to register custom enchantments, painting variants, damage types, and more over the next few years.

There is no requirement for plugins to adapt to this system; in fact, we actively discourage people from using this system unless they need to use it for something. The reality is that most plugins do not need to opt into using the early bootstrapper stuff, but it's there for the plugins that want to.


Spigot hasn't cared to interact with the community outside of its little cubby hole for well over a decade now, and the last noticeable interaction we had with the project was an "if you start sending us all your patches and kill off Paper, I might let you join the spigot team". The only real community overlap I've seen is active paper developers going over to Spigot to try to collaborate on aspects like API design that impact us, such as the Item/BlockType APIs, which are much more in line with our original vision we had 10 years ago. The only reach-out we ever got from there these days is the odd contributor who wants our input on something they worked on.

--

We have so many patches over Spigot that we weren't able to explore our patches folder on GitHub for the past year, and the paralysis of "but, spigot might expose API for that" often made us stall working on or merging PRs for such features, such as the work we'd started to do on breaking down Material in preparation for stuff to be registry driven (as well as the well-needed separation from that broken API concept), something Spigot finally accepted needed to happen, almost 10 years after core project leaders in Paper identified the need for this.


Mojang's recent changes are also "fun" in that releases are more frequent and much heavier on the workload in order to rewrite parts of the game, especially when dealing with the unstable output provided by upstreams' tooling which frequently caused conflicts due to them using a much older decompiler which produced more unstable and less 'unrefined' output, we have a fraction of the decompile fixes that spigot needs with the entire source subtree decompiled vs the partial decompile that spigot performs. Thanks to taking advantage of and collaborating with projects within the community, our source tree is much nicer to work with.

The nature of Mojang's new release cycle also allows them to release new features and iterate on them. Rather than the ping-pong, pong-pong, pong we'd get where you'd deal with a substantially large update followed up by what are often smaller fixes, the releases are now more ping-pong, ping-pong. This means that we're no longer dealing with one or two substantial updates a year combined with a few quick ones but multiple sizable releases a year. Part of the reason we've been able to manage this thus far is more a set of happenchances; we can't start to work on anything until our quasi-closed-source upstream performs a release, by luck, the timezones generally mean that this is an early afternoon for us Europeans, assuming he doesn't hold a release hostage, we can generally preplan to some degree for people to be around to start, however, it's only through the fact that our team we've managed to build is crazily committed to developing this software for the community and is willing to pull off the crazy hours and work around the clock, which is honestly so unsustainable I'm surprised that we've managed to pull it off for as long as we have.

--

It's also worth remembering that one of the first changes Mojang did on this release cycle was rewriting the entirety of how ItemStacks are represented, migrating from "just a blob of NBT" into a much more structured and defined manner of representing this data, with items now defining their data using prototypes rather than sporadically hardcoded behaviour across the codebase; These changes were probably one of the more notable divergences from Spigot we've had here;

1) The ItemMeta API that they're so insistent on refusing to migrate away from is broken and fails to represent how items work in the game, i.e. you cannot query attributes about a food item in vanilla in their API; only items with that component overridden by plugins, manually; That means that you can't query components which are actually on the Item itself and would thus need to use internals or hardcoding, to perform such operations.

2) Spigot opted for compatibility of legacy API behaviour in a manner that transforms "I want to hide the attributes on this item" into "I want to disable all of the default attributes on this item, turning all of my tools into performing worse than wooden tier tools", rather than actually addressing the fact that ItemStacks are a bit less malleable on this front. In terms of working with the community rather than sticking in our corner, we've been able to highlight to Mojang that many members and we dislike this underlying change as it creates a bunch of issues; as for what Mojang will do with that, we're yet to see, but, at least we know they know the discontent of the bundling of some of this data on their components.

It's worth noting that we already saw the signs on the wall and had started work on a Data Component API when Mojang released this change, a welcomed happy surprise that we were able to adopt directly to cater towards that underlying data representation relatively easily;

And that's before you get into API that Spigot generally refused to support for the better part of a decade, i.e. the Biome API only just got support for custom biomes, something we've had primitive support for in Paper for years, but even as much as we wanted to, couldn't work on replacing it as, at first, we'd have to break API compatibility; Then, after a few years, they finally accepted that it needed to happen, in which, we where then stuck on waiting for them to decide if and how they're going to do it; Do they go the route that allows us to deprecate the older API and move forward with the new, and properly expose the underlying data represented by Biomes, or, do they go the route that keeps legacy plugins work for a millennium and fail to expose any modern information about Biomes to plugins. They, of course, opted for the latter.

--

As much as I'd love to say, "Paper is forever," one day, I and the many others I interact with on this project daily will one day get too busy and have to move on. For that, we will need to be able to onboard new developers and find people who are able and willing to replace myself and other team members as the time arises. There are many people out there who fit that bill, but the project's stalemate was just not conducive to that.

The hard fork isn't something new; it has been discussed with the community and other developers for years. Mojang's new release cycles, our desire to work on supporting many of the new things Mojang is increasingly offering in the game, and dealing with the fact that we were struggling to onboard new developers means that we hit our "now or never"; and now, rather than worrying about how we might have to wind this project down over the next 5 years, We're more focused on ensuring that the next 5 years is spent on preparing for the next 5 years after that. The hard fork was pretty essential to the life of this project, and we hope that many are willing to join the ride with us over the next many years, but, it is ultimately your server.

--
NB: apologies that this got kinda rambly
I'm glad to hear these interesting news about Paper development. As a developer, I fully understand the difficulty of Paper's work in this situation, as well as the need to strike a difficult balance between "supporting new features" and "annoying upstream code" every time.

I must also admit that Paper provides more modern and numerous features than Spigot, and to be honest, many of these Paper features should have been the work that Spigot needs to do. Indeed, many of those Bukkit plugins also use Paper API to complete their functions - after all, not all plugin developers are always willing to deal with NMS.

I admit that my concerns are somewhat unnecessary for excellent Paper developers, but I think the content mentioned in the comments, after appropriate supplementation, may also be published as another announcement in the community to enhance people's confidence (or developer interviews or the like). It's not a bad thing to talk about such things in a rambling manner, as there is too much background information that needs to be explained to the audience.

But obviously, currently Paper development still relies on some packages from org.bukkit. Perhaps one day you will replace them all with io.papermc.paper
: )

Hey, it seems that no matter what, we need to say goodbye to Spigot.