Oh I see, I thought you were changing your workflow as a result of the export format change. Yep, saw your stuff, very cool! 
Export format has changed!
Hi Spine,
I'm trying to wrap my head around new workflow with these changes. On my team we have 20 animations per skeleton, often worked on by separate designers. Previously an new/edited animation would be imported into the "master" file as they were completed and that worked fine. Now there is no more "import animation" option, only import skeleton with included skeletons. In my case we want to import just a certain animation. I'm not sure how to do that now. ArtizensAnimator - it sounds like you're facing a similar challenge, did you find a work around?
Thanks
Hey!
Yes, jb.tellez that's similar to the issue I'm having, and I havn't been able to find a work around yet.
I tried importing an older JSON animation file, but alas, it was not allowed!
It seems like we'll have to wait for Nate's magical fingers to code the Drag and Drop function in the animation Tree.
I can see the benefit of using just one file for skeleton and animation data but couldn't this have been just an export option to combine the data into one file instead of eliminating the separation all together?
I haven't seen the new format yet but I would think it would just be a case of:
<file>
{ Bones [] },
{ Slots [] },
{ Animations [ walk { [...] }, jump { [...] }] }
</file>
Yeah it would have been a cool thing to be an option rather than cut off entirely.
I've got an older version of Spine working now, one that another of our team didn't open so it didn't auto-update. So I was able to export all my animations individually....But when you re-import the animation files, it loses the Spline Curves and the slot visibility!
Which is a bit of a problem to say the least.
How long do you think it will be before we can drag n Drop animations from one skeleton to another?
More options isn't better. Fewer options that still handle all the use cases is always better. I didn't want multiple export file formats, the simplicity of one file format was the whole point of the change.
Thanks for explaining your use cases. I see how you guys are using animation import to spread work across your team.
Import was implemented to allow data to be pulled into Spine from other tools. Eg, someone used this to migrate data from Spriter to Spine. Import wasn't intended as a way to move skeletons and animations from project to project or skeleton to skeleton.
I've implemented a new feature: Import Project. This allows a skeleton or an animation to be imported from a project file into your current project. This can be used in your workflow described above to pull animations into a "master" project.
Animations imported this way can be imported to a skeleton different from the one the animation was originally designed. This only works if the bones (and slots and attachments if keying slots or attachments) have the same names in both skeletons. If not, you will get warnings showing what could not be imported. Eg, try importing the dragon "fly" animation on top of Spineboy. Only the "head" bone is the same, the rest will give warnings. The import still works, it is just partial.
As a bonus, due to the way importing from a project had to be implemented, you now have "Duplicate" buttons for bones, slots, attachments, and skin attachments. Enjoy.
This new stuff is in v1.3.0+, available now. I tested it pretty thoroughly, but there may be issues. Always keep a back up of your data!
Thanks Nate! My team will try out our "spread out" work flow with latest Spine and report back.
Thanks Nate!!
I've been using this for the last few hours and it's exactly what we needed.
Hope it's working for you jb too.
I'm a little worried about opening a project I haven't touched for a few weeks... There is no way to have archived versions of the editor? So if I have minor additions to an animation that hasn't been touched in awhile, it won't require redoing a lot of small/custom changes in the older runtime?
I could always block spine from internet access so that it will never update, but it might be nice to be able to use the older version, in case a quick update of the project might turn into a much longer update in the runtime too.
Old project should always be able to open with a newer version. Auto update is relatively new, there is no way to archive older versions of Spine. What you can do is click the cancel button when Spine is downloading a new update (you might need to be fast if you have a super fast connection). This will cancel the download and Spine will run with whatever version you had. You could also block Spine from the internet. But it's really best if everyone is running the latest version.
I have updated spine-python to take advantage of the new format. All of the examples for pyguts have also been updated.
There are tarballs on pypi.org and source on github (search for spine-python).
Cheers