- Изменено
Runtime crash(c++). When try to open old files.
We have a lot of animations done in the previous version of "spine". We update the program and runtime, but the new runtime does not open the previously made atlas/json files pair. It crashes inside curve loading section.
So we cant use new version and new version features because we cant change previosly made data. 
Hello,
If your work wasn't saved in the newest version of Spine, could you try downgrading to your previous version of Spine, and the runtime that corresponds with the version of Spine that you're running?
If that doesn't help, could you try the actions at the link below?
Versioning - Spine User Guide: Recovering work from a newer version
Yes we reverted previous version now. But we want use new features very much, and can't do it because new runtime, can't load old json files. And we cant reexport it in new version because we can't change data of done projects.
Newer versions of Spine should be able to open older project files; would you mind sharing the crash log and information about what operating system you're using?
Also, are you using any kind of antimalware/virus protection/security software? If so, most are known to interfere with Spine.
Crash logs can be found here:
Windows
%UserProfile%\Spine\spine.log or C:\Users<user name>\Spine\spine.log
macOS
~/Library/Application Support/Spine/spine.log
Linux
~/.spine/spine.log
We have some missunderstanding, i talk about c++ runtime, not about Spine editor.
We had version 3.8 of editor and same version of runtime. Now we try to update to latest version, we update editor and update c++ runtime. After that i rebuild old project with new c++ runtime, and it crashed in runtime load function when app trys to load json file created in version 3.8.
We can't re export this json file from new editor, because we can't change resources of done projects.
It's not possible to load old data with newer runtimes:
Versioning - Spine User Guide: Synchronizing versions
You will need to export your data with the newer version to use the newer runtimes. If you only have JSON data you can import the data into the old version, save a project file, and then export it with the newer version. If you have many projects, you can do this using the CLI:
Command line interface - Spine User Guide
Unfortunately, we can't update application data if it was already released, but we can update executable and libraries, and we do it from time to time. So it will be great to have one spine runtime library for all projects new and old. And we can't have a unique spine runtime library for each project. As I see we should stay on version 3.8 forever .
it was very sad to find out that the library is not backward compatible.
Sorry. The backward compatible layer is in the editor, not the runtimes. If the runtimes had to read data exported from ANY of the many previous editor versions, it would be a lot of code. That would be bad because there are many runtimes in many different programming languages, so it's better to keep the runtimes lightweight.
It seems odd not to be able to update the data. I guess you have a data download or some other mechanism that doesn't support versioned data? That seems like the only way.
One data package can be used by different builds and version of application. After release , еach build can be in use.
We can't store unique data pacakage for each build, we talk about huge data size.
Can i link more then one verion of spine runtime in one applications? I think i can't.
Any way , runtime crash while loading json is bug in my opinion. If json of incorrect version load should be finish by exception or false return code.
You could ship a single binary with both runtimes by changing the namespace of all the classes of one runtime in the .h/.cpp files. The compiler will then emit different symbols post mangling, so both runtimes can live side by side. You'd then have to use the respective runtime for loading and rendering.
You are right, that the C++ loaders should check the data version and return an error instead of crashing when parsing the files. We've created an issue here: https://github.com/EsotericSoftware/spine-runtimes/issues/1998
Yes it will works if i put old library into namespace. And if you fix load, i can try to load animation by new version and if it fails i will try use old version.
Is runtime not compatible between major versions only (like 3.0 vs 4.0) or between minor versions too ( like for example 4.1 vs 4.2 )?
If it between major versions only, we can think about this solution, put old runtime for old legacy projects, and put new runtime for current project.
But if the minor versions ( like for example 4.1 vs 4.2 ) will be not compatible too, its wrong way and we will forget about any updates.
Runtime compatibility is guaranteed only for patch versions (where version numbers are major.minor.patch), so 4.2 runtimes can't officially load 4.1 data. In practice sometimes JSON data from older versions is OK (though not officially supported), but not binary data. The differences between 3.8 and 4.0 are very large, so old JSON data isn't compatible.
Even though minor versions aren't compatible, I don't think it changes the approach. You could still use multiple runtime versions. If you don't want to bloat your codebase with many runtime versions, you don't need to update to every new major.minor version. Maybe just once/year, or maybe just do it once, so your animators have access to 4.0. In that case you may want to wait for 4.1, which improves on the graph and other new features added in 4.0.
I think we should wait for 5.0 and after that implement 4.9 to our engine, to be sure that all bugs are fixed in 4.х. Any way it will be posible only after you fix load function in c++ runtime.
We don't release a non-beta major.minor version until the editor and all runtimes work well. It can be considered stable when released, though any bugs we missed are fixed over the next few weeks or months after the release. Each new major.minor version adds significant new features and can generally be considered a big improvement.
Thank you for fast feedback.