lxs Trying a new runtime version becomes risky and expensive
It is indeed risky and should be done with care, same as with upgrading any dependency. It doesn't have to be expensive. If you have a good build system or asset pipeline setup, re-exporting for any particular version is free. There are also other benefits to having your projects exported as part of your software build. You set it up once and then upgrading to any version is just changing the version number in a script.
lxs Backward compatibility for Spine 4.2 exported data where possible.
While this is possible, the main reason we don't do this is to keep the runtimes streamlined. The massive amount of conversions and other ugly bits to be able to load any of almost 700 older versions happens in the editor, allowing the runtimes to be smaller and just load the data and go. It also allows us to make big improvements to the runtimes without being bogged down with how things used to work.
lxs A clearer migration mode or compatibility warning before the runtime upgrade breaks existing assets.
All major.minor runtime upgrades require re-export. Patch versions are always safe to upgrade.
lxs A batch re-export or batch migration tool for existing Spine assets.
We provide scripts here. In 4.3 we have added many CLI features that makes processing many projects easier (globbing, etc, documentation is in the works).
lxs More detailed documentation explaining which 4.2 assets must be re-exported and why.
We have this page: https://esotericsoftware.com/spine-versioning
We could sort of give backward compatibility for smaller updates, but it would bloat the runtimes and take up more of our time, and still jumping to a new version would be no small thing. While we strive not to change behavior, sometimes things work differently and you may not get exactly the same results. For example, by fixing bugs in 4.2, constraints may be applied in a different (correct) order in 4.3. This looks like a bug and requires manual fix up, but it's actually a fix that is important for complex constraint setups. That means you should review all your skeletons and animations when upgrading.
There are likely some differences in the runtimes, so you may have some code changes. Then you need to test that the particular ways you use the runtimes still works exactly like it used to in your app. In 4.3 the API changed quite a bit, as we now have a "pose system" that was needed to make constraints super solid.
Re-export is actually one of the easier parts of upgrading, if somewhat painful the first time. Some users throw away their .spine project files, for some terrible reason, and have to do an extra step to import their data into a project file.
I'm all for making this easier, but there would be some tradeoffs to a different approach.
Re: re-drag the new animation assets, Harald is our Unity expert and can comment on this (he'll be here Monday) but I believe you can replace the assets without needing to make changes to your Unity project.
