ghorsington
commented
2 years ago I agree that this will break any code that relies on the current API, but on the other hand, I think that in the long run, this is the correct thing to do.
How about introducing this behaviour as an opt-in for 1.x versions? Specifically
- Allow both include/exclude options. The options will be exclusive, i.e. specifying both is an error.
- By default, apply the current include behaviour on 1.x. Also, emit a warning that includes behaviour will be removed in the next major version
This way, we can at least provide a warning about this while still retaining the current behaviour until the next major release. Mod loaders can then choose what behaviour to use (in the case of BepInEx, we can enable exclusion behaviour right away for our doorstop 4 branch, but inclusion behaviour will be needed for current GTFO mods until they migrate too).
Another option is that I can make a separate next branch into which we'll start adding major breaking changes for the next major 2.x version. I was thinking about making such a branch, but I just didn't since I haven't yet made any major breaking changes.
How about these two options -- which one would be better? Any other opinions on how to integrate this into master or address this being a breaking change are welcome.
ds5678
Game developers often use the global namespace and external libraries when making their games. For modding, this can cause conflicts during mod development. Although we currently have a way to prefix assemblies and namespaces, it's an opt-in system. An opt-out solution would be better because mod loaders can't anticipate all the assemblies game communities might want to prefix. By prefixing everything but UnityEditor and UnityEngine, we can prevent all potential conflicts between generated interop and managed libraries.