Hard fork process

[kennytv]

We have to:

Tasks

Preview Give feedback

1. Apply all per-file patches (about 800)
2. Apply all feature-based patches (about 30, but REALLY large ones)
3. Publish an initial test build outside the API to fix less obvious issues
4. After fixing issues, push to main and publish initial builds
5. Push paperweight-patcher - see here for exampless
6. Provide a script and info to contributors on how to update their pull requests
7. Do more fixing before exiting experimental builds
8. Non-beta paperweight release

Applying all patches will likely take a few weeks. Make sure to join our Discord for discussion and more fine-grained updates!

See our forum post for more information: https://forums.papermc.io/threads/the-future-of-paper-hard-fork.1451/.
You can also see our previous prep work on here: https://github.com/orgs/PaperMC/projects/6/views/1
Aaand you can see the current update branch here: https://github.com/PaperMC/Paper/tree/dev/hard-fork

For our dev team:

• clone into dev/hard-fork, set cleanPaperRepo in ~/.gradle/gradle.properties to a pre hard fork 1.21.4 Paper project sources root (Paper-Server/src/main/java)
• gradlew applyPatches
• Repeat:
  • gradlew gibWork
  • Tick the entry in the per-file patches issue immediately
  • if it applied correctly, continue, else look at the rejects file and apply the missing hunks
  • open the patched files and see if they compile, if they don't gradlew checkWork to move the file to the old repo; fix up compile issues; press enter (which will copy the files back)
  • git commit --amend in the paper-server/src/vanilla/java dir
• gradlew rebuildPatches

make sure IJ detected the new git repos:

[spring-dependency-management]

Can we aim to have as few feature patches as possible? their existence kind of defeats the purpose of per-file patches, as what you see in the patch files isn't what you get, since it will be overwritten by the feature patches, also they cause errors with fixuppatches if you dare to modify a file that feature patches also touch

[Owen1212055]

Can we aim to have as few feature patches as possible? their existence kind of defeats the purpose of per-file patches, as what you see in the patch files isn't what you get, since it will be overwritten by the feature patches, also they cause errors with fixuppatches if you dare to modify a file that feature patches also touch

This is probably better to discuss on the discord, but generally it’s very dependent on the feature itself for whether or not it becomes a feature patch… especially when it’s very diff noisy, so allowing it to be dropped on updates easily is just undeniably useful. They don’t defeat the purpose at all, they are there for a separate purpose roughly.

[AltTheAi]

While doing a hard fork, do you think it would be viable option to switch to GraalVM native image? This would drastically improve performance while sacrificing the garbage collector which means that plugin developers would have to be more careful. I think the advantages outweigh the disadvantages

[electronicboy]

No, there is no interest in burning the entire ecosystem to adopt an alternative JVM platform which comes with its own pros and cons. native images do not support loading jar files and would require a whole bunch of work to adopt a mechanism to support this for very limited gain.

[codebycam]

So what could be done to improve performance without going the Folia route?

This isn't the best place to discuss this, @SolsticeSpectrum. You can join us on Discord and provide a spark report in #paper-help along with the issues you're facing and someone may be able to help you with your performance!