When a new version of Spine is available, it will ask at start up if you want to update to the new version. Before clicking Yes, you should consider what runtimes you are using (if any). Often Spine versions have features that are not yet supported by all official runtimes. In other cases, you may be using a 3rd party runtime or a game toolkit whose dev team integrates Spine on their own (such as GameMaker) and they are unlikely to immediately support all the features of a new Spine release.
Animators should freeze their Spine editor version to match the Spine version supported by the runtime being used. Only when the runtime is updated to support a newer Spine version should animators update their Spine editor version to match.
For the official Spine rutimes, each runtime webpage tells what Spine version is supported and lists any caveats for that runtime. Note that spine-libgdx is the reference runtime implementation and it is always up to date for every Spine release, since Spine uses it internally.
People have asked why we release a new Spine version before runtime support is available. Doing this gives animators the option to begin using new features as soon as possible. Not all animators are blocked by runtime support and they don't mind continuing their work until the runtimes are updated. Also, some animators are exporting to images/video and don't need runtimes at all. Even if we did delay Spine releases until the runtimes are ready, it would still take some time for 3rd parties to update their game toolkits, so many of you would still need to be aware of when you should update your Spine version.
When you have a dependency on other tools and software, there is just no getting around being weary about when you update the dependency. There may be bugs or other unforeseen problems that can cause a disturbance and equate to lost time and money. When you do update your Spine editor and runtimes versions, it is always smart to check to make sure your app is working as it should. If not, please report the problem and while we fix it you can revert back to the last versions that were working for you, with no time lost and no be blocked waiting for us.
Sometimes users are not aware of how this versioning works. They update Spine to the latest, do a lot of work, then find that the runtimes don't support their animations. We are working on ways to make versioning more clear, eg by showing informational messages inside Spine. The kicker is that old versions of Spine can't open projects saved with newer Spine versions (but newer versions of Spine can open projects saved with any older version).
If this has happened to you, first remember that Spine saves a backup every time a project is saved. It also saves a backup every X minutes, if you have that enabled. You can go back to a previous version of your project by finding the last backup that was made with the older Spine version. If you have done too much work in the new Spine version that you don't want to lose by using a project backup, then we have written a small tool that will help.
The JsonRollback tool converts the latest JSON data so it can be imported into an older version of Spine. It does this by adding, modifying, and/or deleting parts of the data. This can be destructive, since features like shear or paths that don't exist in older versions of Spine have to be deleted. It should be used with caution.
Edit: As of Spine version 4.0.68-beta, the JsonRollback tool is no longer needed. Instead, you can choose an older version when exporting JSON. This is equivalent to using the JsonRollback tool, but is easier. Going back to an older version may still lose data and may still require manual fix up, such as deleting attachments or constraints that do not exist in the older version. Exporting to an older version is still not a recommended workflow, it is provided only to help recover work after from the catastrophic situation where a newer Spine version was used unintentionally.
The process works like this:
- Open your project with the newer version of Spine you were using.
- Export your project as JSON data. Make sure you check
Nonessential data.
- Run the
JsonRollback tool.
- Change your Spine version to the older version you want to use.
- Import the JSON data.
The JsonRollback tool is distributed along with the Skeleton Viewer. Download the skeleton viewer JAR file, then run it like this (where the "to" version can be 3.8, 3.7, or 2.1):
java -cp skeletonViewer.jar com.esotericsoftware.spine.JsonRollback input.json 3.7 output.json
Java is required to run the tool.
Please note that we are actively working on the runtimes and expect them to be done in the next couple weeks. We are also expanding the Spine team, though that has unfortunately taken slightly longer than expected which is why we are currently so far behind on the runtimes. We'll get a handle on things again soon and everything will be much more awesome than before.
Edit: We have updated the JsonRollback tool in Skeleton Viewer 4.0.54-beta to support specifying a version of 3.8 to go from 4.0.xx to 3.8.99. However, there are some drawbacks: all curves will become linear, separate translate, scale, shear, and color timelines are lost, and constraint translate Y and shear Y are lost.
Edit: As of Spine version 4.0.68-beta, the JsonRollback tool is no longer needed. Instead, you can choose an older version when exporting JSON. This is equivalent to using the JsonRollback tool, but is easier. Going back to an older version may still lose data and may still require manual fix up, such as deleting attachments or constraints that do not exist in the older version. Exporting to an older version is still not a recommended workflow, it is provided only to help recover work after from the catastrophic situation where a newer Spine version was used unintentionally.
