Leoss

Hello Nate,

I really like the job you are doing, fixing bugs and adding new features is great, and Spine is really a good product, but can you please do something about backward compatibility for the Unity/csharp runtime?

In the last two weeks of fixing bugs and adding new features for the Unity/csharp runtime, there were both interface changes (that made my program not compile anymore) and functionality changes (that introduced some hidden bugs).

I don't know if there is a particular reason you are doing breaking changes (I think maybe the lack of time) but you really have to do something about it...
Each time I update to your latest runtime (for some bug fixes for example), I have to spend hours trying to hack into your code to make things compile again and to test if it's really working like it used to be.

Example of unnecessary interface change:

The AnimationState function "
public TrackEntry SetAnimation (String animationName, bool loop)
" was changed to "
public TrackEntry SetAnimation (int trackIndex, String animationName, bool loop)
"

You could have easily made the trackIndex parameter optional, or you could have created a function like this:
public TrackEntry SetAnimation (String animationName, bool loop) {
return SetAnimation(0, animationName, loop);
}
Next is: changes to functionnalities that were already working.
Before, I could have fixed animations with "loop" setted to false, now you are forced to set it to true... It's really annoying to find elements that used to work fine breaking for some unknown reason.
It's really frightening to think that updating to the newest version of the runtime can potentially add new hidden bugs...

I know that you are already drowned by work, and that this tool is still in development, but it's one more reason to try to put your effort into making your tool able to scale fine.

Maybe you should point more explicitly when you are forced to do breaking changes.
(And maybe have differents versions, like lot's of API have, to know explicitly that going from 2.3.2 to 3.1.2 is risky, but going from 2.3.2 to 2.3.5 is not.)

I hope you understand my point, and again: thanks for your hard work.
Leoss
  • Mesajlar: 17

Nate

Recently AnimationState was completely rewritten, which is not a typical update, and a number of things changed about how it works. You're right that I could have provided methods that don't have a track index to avoid breaking existing code, but the refactoring was big enough and I felt that it was clearer in this case to explicitly tell which track was being changed. I try not to break things, but I also try to think about what is best for the API in the long term.
Before, I could have fixed animations with "loop" setted to false, now you are forced to set it to true
I'm not sure what you mean here?

Currently we don't have a release system for runtimes. By updating git, you are pulling in the latest development. This is risky and I don't recommend doing it unless you have time to understand the changes and ensure there are not bugs in the runtimes or caused by the update. Right now runtime development is moving very fast as new features are added and refactoring is done. I expect it to settle down soon.
Kullanıcı avatarı
Nate

Nate
  • Mesajlar: 12213


Dön Runtimes