[FML 9 Backport] annotate mixin configs with compat level

[lukebemish]

Mixin configs are annotated with a compatibility level (a fabric-mixin feature); this defaults to an FML-provided value, but mods are able to override this when declaring the config in their neo.mods.toml. This allows mixin to be updated even past a breaking change on old MC versions; the FML-provided-default means that mods still get the old behaviour but allows mods that need it to opt into the new behaviour, while ensuring that the new, fixed behaviour is the default on new MC versions during BC windows. Basically, it means we can backport new mixin to old MC without breaking mods.

During a BC window, if the version of mixin is bumped past a new compatibility level (in FML or in neo or whereever -- there is currently not a single source of truth for this), the DEFAULT_COMPATIBILITY must be bumped so that the new behaviour is used.

The compatibility field of a mixin config declaration in the neo.mods.toml may be used to override the FML-provided-default compat level; this field takes a mixin version (aka, 0.14.0 or the like) the behaviour of which you want. Asking for a version greater than the currently running version of mixin is an error.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[LlamaLad7]

I think it should be allowed to specify something newer than the current latest compatibility level, just not newer than the current mixin.

Also, have you considered picking the larger of the default and overridden values, to prevent staying on old behaviour past a BC window? I think it's good to move people off bad behaviours generally.

[lukebemish]

I feel like people should be able to pick the old behavior if they desire -- I can imagine this being relevant for something like connector, effectively linking up the behavior on fabric this way, though to be honest I'm not quite sure how their system works with respect to mixins. But in general I think giving folks the freedom to request older behavior as well as newer than the default is sensible; if we are going to prevent explicitly requesting older than the default, I think it should throw then instead of just taking the max, to fail early and in a clear way if we think people shouldn't be doing that to begin with. I want the version, if you explicitly request it, to be a guarantee, not something FML could upgrade on you.

In terms of allowing a version up to the current mixin version -- that should be doable; is the current fabric mixin version exposed by fabric-mixin anywhere? Worst case I can use the implementation-version I suppose.

[LlamaLad7]

1. Fine, I agree about the connector case
2. Don't think it's exposed in any other way yeah

[lukebemish]

Alright, fixed it up so it uses the current mixin version as a cap rather than the highest compat version -- since I agree, that's a bit more intuitive.

[LlamaLad7]

But in general I think giving folks the freedom to request older behavior as well as newer than the default is sensible

I actually disagree now. Connector won't go via this at all, it will decorate manually.
If you specify a behaviour and then update to a newer mc version, you won't notice that there's a newer one.
I think you should be forced to update in every BC window. Throwing would be fine for me.

[lukebemish]

Mmm. Okay, yeah, that seems reasonable. One slight worry is, is it even possible for something else to add mixin configs (and to annotate them)? I'm... Not entirely sure it is. Post-mixin-in-FML PR actually I'm reasonably certain it isn't because the mixin service isn't initialized there till the transforming class loader is built. So basically -- at what point in time would someone like connector, with a real reason to use the old compat levels, register their configs manually? I don't feel good locking this down, knowing that some folks will likely need the other behavior, unless we have a clear answer to that. Lemme poke this though -- maybe there's a clear enough place to do so I'm missing.

[lukebemish]

Alright, so looks like at present and post that change you can register the configs any time after the launch plugin is set up so there should be some opportunities. That may change if transformers are reworked the way I've imagined, where everything needed there is loaded exactly as the class loader is built, which happens later.

But if I do the validation on the parse end, anything loaded with FMLs locators will have that requirement but another locator or whatever it's called could presumably not require that if it wanted. So I think it's all good.

[lukebemish]

This is currently blocked by the fact that the approach used to get the current mixin version (Package#getImplementationVersion) will not work if mixin itself is loaded as a module. Marking this PR as a draft until that is resolved.

[lukebemish]

A mixin version exposing its module version is available! So this should be good to go w/ that version bump.