[7.0] Begin ForgeGradle 7.0's Release Candidate lifecycle

[Jonathing]

The merging of this PR will mark the beginning of ForgeGradle 7's Release Candidate lifecycle. This crucially means a few things:

• API breaking changes will no longer be accepted.
  • All changes to API must strictly be additive until ForgeGradle 8.0.
• There might still be some bugs that need to be ironed out before the full release.
• As we get closer to full release, I will begin slowly phasing out ForgeGradle 6's development (though all versions of ForgeGradle are open to bug fixes and PRs).

As an additional note, I'd like to begin stabilizing the other plugins as well. This includes JarJar Gradle, Multi-Release Java, and JVM Aggregate Testing.

[PaintNinja]

I'm unclear on the current state of FG7, so take this statement more generally:

I'd rather the focus be on getting all the core functionality working reliably before locking in the API. Some past builds of the betas had breaking changes as it was later discovered that it couldn't be fixed without doing so.

This helps avoid unintentional inflation of the major version for the sake of fixing something that requires minor breakages.

[Jonathing]

Fixes can always be made without needing to break the API. But if we make a release candidate and start telling people to use it to help us test/migrate, then there's an API breakage that requires them to change something in their buildscript instead of just upgrading ForgeGradle, that can put a bad taste in people's mouths. That's why I am adament on an API freeze for the release candidate cycle.

Please give me a clear list of the core functionalities I need to test over the next few days before starting release candidates. I'll start by making #988 a blocker for release candidates.

[PaintNinja]

Fixes can always be made without needing to break the API.

Not always... that's my point. I'd prefer to delay the RC in favour of more fixes during beta first, just in case you get unlucky and end up needing to break API, as that way it wouldn't be unexpected.

People can use fixed build numbers in their scripts during the beta period as usual. Yes that doesn't solve the MDK/buildscript update issue but isn't any worse than what we have now and would be a huge upgrade for those currently stuck on FG6 and wanting to help with real-world testing.

Once the core functionality is reliably stable and tested, then start RCs.

Please give me a clear list of the core functionalities I need to test over the next few days before starting release candidates.

• Able to build an existing non-reobf Forge mod
• runClient task works with resources present (i.e. game loads with panorama background, no grey bg. Mod block texture present ingame)
• runServer task works
• Able to see decompiled MC sources in IDE
• Able to apply an AT and compile against the now-public thing from mod code
• Changing Forge build should work
• Changing MC version should work (assuming mod code worked across the two versions)
• Able to build an existing non-reobf multiloader Forge mod in a multiloader build setup

JiJ becomes much less of a big need once MixinExtras is bundled in Forge and enabled automatically.

Parchment is a nice to have but not a blocker for starting RCs imo. There's currently uncertainty if it'll be continued after Mojang distributes non-obf binaries

[Jonathing]

Please see #996 for limitations on changing the Forge and Minecraft versions without re-syncing the project or explicitly running syncMavenizer

[Jonathing]

I've checked everything that is confirmed working so far.

[Jonathing]

Gonna push back my preferred due date for the first release candidate by a week so I can give myself enough time to confirm compatibility in multi-loader setups.

[PaintNinja]

Needing to resync after changing versions is fine, that's already the norm for FG6. Presumably there's a check or error message if someone forgets?

[Jonathing]

Yup! It is attached to compileJava. Though that reminds me to also attach it to the run tasks as well.

[Jonathing]

Able to build an existing non-reobf multiloader Forge mod in a multiloader build setup

jaredlll08/MultiLoader-Template#107

Link more multi-loader templates if you got them, please.

[Jonathing]

Good evening. With the exception of Eclipse run configurations, I believe that ForgeGradle 7 is now in a state where it can be used in production. I've tested dropping it in as a replacement for ForgeGradle 6 in the template I linked earlier, along with bumping the Gradle wrapper to 9.2.0, and everything went smoothly.

As for Eclipse, unfortunately, JavaExec tasks still cannot be hooked in with the debugger. This issue can be tracked in eclipse-buildship/buildship#1130. For now, what I can do is make a successor to the genEclipseRuns task in ForgeGradle 7 that invokes Slime Launcher to make the configuration for us. It needs to do this since Slime Launcher is responsible for any classpath changes, downloading assets, and other pre-bootstrap tasks.

To clarify, I will not be recreating the genIntellijRuns and genVscodeRuns tasks, as those IDEs are fully capable of attaching the debugger to the Slime Launcher run tasks.

I will leave it up to Lex as to whether the inclusion of genEclipseRuns should be a blocker for the Release Candidate lifecycle or the full release.

For now, I will begin working on the full documentation, as well as the upgrade primer from ForgeGradle 6.

[PaintNinja]

Link more multi-loader templates if you got them, please.

• https://github.com/Tslat/Mod-Templates
• https://github.com/tr7zw/ProcessedModTemplate
• There's also the rabbithole of Stonecutter and related projects