From Unity 2017.2 beta Release Notes:
We make the Spine runtimes source-available so that you can read, adapt or remove parts from the code you don't need.Editor: Added assembly definition files feature for script compilation pipeline in the editor. Allows you to define your own managed assemblies based upon scripts inside a folder. By splitting your project's scripts into multiple assemblies, script compilation times in the editor can be greatly reduced. Note that the latest version of Visual Studio Tools for Unity is required for this feature to work with solution and project generation for Visual Studio.
Up until Unity 2017.1, if you place your Spine runtime code in Unity's special folder named
Plugins, it will compile the Spine runtime code with your game's Plugins assembly. This means you could work on your game code, and your plugins code separately, and they will also compile separately, and only the assembly that changed needs to recompile.
With 2017.2, you will be able to define more assemblies for separate compilation.
We will likely provide the assembly definition files with the unitypackage once Unity 2017.2 is released (sometime soon).
To start and to keep setup simple, we'll likely be putting all of
spine-unity(and all included modules) into one assembly.
If your existing code uses some fields or methods that are marked
internalbecause they were all originally in your game's main assembly, this may force you to take stock of your code regarding how your classes and functionality are organized. Deeply-Spine-integrated functionality may need to be included in this new Spine assembly.
However, over the past several months, we have prepared for this change by providing and recommending using or caching public properties over internal fields.
If you feel like your code is reasonably detached from Spine's internal systems but you still need to use that
internalmethod, property or field, we would appreciate your feedback and we'll figure out how to expose it in ways that can make sense for everyone.