Question to cocos2dx developers: why is there so much API mismatch between 2.0.1 and 2.0.4?

Question to cocos2dx developers: why is there so much API mismatch between 2.0.1 and 2.0.4?
0.0 0


I’ve developed my game with cocos 2.0.1 on iOS and Android. Now my boss gave me a task to port that game to Blackberry platform.
I found support for Blackberry in 2.0.4 release. But in the same time I found a lot of differences in API between 2.0.1 and 2.0.4 - most of these in create() methods: in 2.0.4 you’ve removed a lot of create(param) methods without any deprecation and replaces them with createWithXXX(param).


CCArray::create(unsigned int capacity) > CCArray::createWithCapacity
> CCSprite::createWithSpriteFrame(CCSpriteFrame *pSpriteFrame)

I’m sure I’ll find more along my porting efforts.

Is it good policy for the project? I found this very bad practice to break API in such way within the same 2.0.x series of releases, without any deprecation period.
Other open source projects I know (and in some of them I was involved to) have good deprecation practice, at least I don’t expect them to seriously change API between minor releases of the project.

Why did you do so, guys? Why?


During v2.0.1 to v2.0.4, we’re designing cocos2d Javascript API with cocos2d-iphone team. So far, we have the unified API set in cocos2d-iphone/-x Javascript Binding and cocos2d-html5. As the result, we decided to follow the same API set with Javascript in C*+ layer. Doing this will no confuse developers in the coming documents. Microsoft’s .NET framework has the same API name in different programming languages. That’s what we want to learn on cocos2d-x c*+/lua/javascript APIs.

And the version number of cocos2d-x follows cocos2d-iphone. For example, cocos2d-x v2.1.2 means this version is synchronising features of cocos2d-iphone v2.1, it’s the 3rd version based on cocos2d-iphone v2.1, the previous version numbers are v2.1.0 and v2.1.1.