It’s all in the numbers …

On September 29, 2010, in cocos2d, by Steffen Itterheim

I assume we’re all eagerly awaiting for cocos2 v1.0 and to be given a download link to click on. The year 2010 started so promising, with v0.9 going through beta during end of 2009 and beginning of 2010. This v0.9 never came out of beta but was re-labelled as v0.99 and released as final version in February 2010 (if I remember correctly, it was either due to the amount of changes or the closeness to v1.0 that it was labelled v0.99). At this point I was thinking that by the end of spring, at the very least, we’d have a final v1.0 of cocos2d.

But 8 months later we’ve just seen v0.99.5 beta 3 release but no v1.0 in sight yet. I’m growing impatient. I’m wondering what the holdup is? The version labels seem to grow longer and longer, as if the labels were trying to prove the point that you can still have an infinity between 0.99 and 1.0 – if you only add enough digits and other stuff after the decimal sign this could go on forever.

So, please, for the love of god, just label it v1.0 already and lets get on with regular 0.1 steps from then on!

Just out of curiosity, I made a quick spreadsheet and hacked the average time between updates in, and it told me that according to this year’s release schedule v0.99.7 will be released on December 24th, 2010 and v1.0 sometime May next year. If version number updates continued at this rate, don’t hold your breath for v1.1 before the second half of 2012.

It’s just a silly estimation based on average days between new versions and their respective version numbers, so don’t take this seriously, or the wrong way. I’m merely growing annoyed and concerned how cocos2d progress has not been reflected in the version numbers in all of 2010, and how version numbers have grown out of proportion and anything I can relate to. Not that it’s any of my concern, but I do believe that doesn’t do cocos2d a good service to continue to label new versions like “0.99.5 beta 3”, and it certainly doesn’t help to portray it in the right light if you compare it to the progress other engines have made over the same period of time – if only in version numbers.

It’s almost as if going “v1.0” meant that cocos2d would be losing its virginity, and that being a life-changing event it shouldn’t happen without about a year of dating, right?

Right?

Well, for what it’s worth, I would suggest taking on the pretty-much-standard versioning style: major version dot minor version dot bugfix/hotfix (non-breaking) releases dot build number. Then go back to the regular release cycle with about two months for each 0.1 step, regardless of what the major number is.

I mean, a major version number change should still introduce something awesome, or useful, or practical, or helpful – in that case just skip the remaining 0.5 or so ahead and bump the major version right away. Personally, if HD support is in and points instead of pixels (what a concept) then that would be it for me. That would be a good v1.0. Get it done and all the bugs fixed, and label it v1.0 so we can all start looking forward to more reasonably labelled releases. Really, it just doesn’t matter that much if you change the first frickin’ number from 0 to 1.

Personally, I would have preferred if cocos2d were now closing in on v2.0. That would be about the version we might be at if the rate from 0.5 through 0.8 had continued at the past update rate. And a v2.0 would be absolutely justified for cocos2d, and I suppose a lot of people would feel much better working with a v2.0 than the current unstable 0.99.5 beta 3.

I hope we won’t see this happening again when cocos2d tries to get pregnant, and labels itself something like “v1.98.7 beta 6 final alpha” around that time to reflect the process, or progress, or lack thereof, or hormone levels, or morning sickness intensity, or whatever.

It’s a frickin’ version number, that’s all that it is!

And it needs some serious increasing to catch up with its level of maturity. Think about what that means to how cocos2d is first perceived by an outsider.

Heck, Unity is now at v3.0, SIO2 is racing towards v2.0, Shiva is close to v1.9 and even the slow-to-release-updates iTorque has gotten to v1.4 by now. Cocos2d is still afraid to go even v1.0 and it’s a shame, because it hurts its reputation, it doesn’t do itself justice, it’s likely to be perceived as being behind the pack and it doesn’t look good in terms of actual progress being made, regardless of the actual work that’s been done this year.


This article was brought to you by ...

I very much enjoy the learning process, the pushing of boundaries (mine and yours and that of technology), having the freedom to pursue whatever is on my mind, to boldly program what no one has programmed before, and to write about what I've learned. Help me help you by browsing the products in the Learn Cocos2D Store.

Tagged with:  

17 Responses to “It’s all in the numbers …”

  1. abitofcode says:

    If apple could stop being quite so inconsiderate and slow down their rate of new products/features then we should reach v1.0 pretty soon.

    • GamingHorror says:

      You think the fault lies in Apple releasing new products & features too frequently? This year saw 3.2 (iPad) and 4.0 and 4.1 being released as the most significant iOS updates, as well as the iPad and Retina Display devices. I don’t see Apple being inconsiderate about their products, or their release cycle, and nothing strikes me as unreasonably complex or overthrowing changes.

  2. Paul Gregory says:

    Maturity isn’t the same as age.

    There is one valid reason for holding off on the 1.0 label, which you don’t dwell on in your blog post, and that’s API stability. I’ve read somewhere that the API is subject to change until it hits 1.0. However, that in itself is another reason to yearn for a speedy 1.0!

    I assume that what this means in practice is whereas things like CCLabel can just be removed between 0.99.4 and 0.99.5, if CCLabel had survived through to 1.0 it would have to stay in 1.1 – albeit with a note in the docs saying “This is slow and you should really use CCLabelAtlas or CCBitmapFontAtlas”.

    So, the important part of “the final v1.0” is that it does finalise the API. Anything in there we’re stuck with for the rest of time – I guess that’s a marriage in your dating analogy.

    I guess what I’m saying is that the reason the number doesn’t look mature is entirely intentional – cocos2d is not as mature as the creator intends. If we must use a dating analogy it’s closer to a father not letting his daughter out of the house looking untidy.

    In the meantime cocos2d is actually out there working for many people who have come to depend on it – but it’s not a brilliant time to be completing books or selling starter-kits. Or for relying on code examples to still work with new releases of cocos2d.

    I’d love this to reach a stable state of maturity soon but I’m glad that while it *is* in flux, the labelling clearly warns us with a sub 1.0 version number.

    Once it’s past 1.0, there is no hold-back on version number incrementing which could better reflect the amount of work that’s gone in. But until then, we’re on numbers that don’t indicate backwards-compatibility.

    • GamingHorror says:

      “API stability”

      I’ve read that too. I can understand the argument. I purposefully left it out of this blog post. I think it’s meant to say “no more breaking changes”. Now, in an ideal world, that would be perfect. But I haven’t seen that happen in any game engine thus far. What’s more important to “stability” is to fix the problem most developers are having eventually: upgrading cocos2d. By throwing in the current version’s source code file into new projects, it’s making the upgrade process much harder than it should be. It was the main motivation for me to create the Xcode project that allows me to keep cocos2d seperate. The breaking changes wouldn’t be nearly as bad for most people if there was a clean and easy way to upgrade cocos2d, and then being able to focus on fixing your own code instead of guessing which cocos2d files need to be updated, which need to be added and which removed.

      Marriages can change, they do change, and if a marriage doesn’t change it either fails or ends up making both partners feel miserable. If we had v1.0 and CCLabel turns out to be a bad idea – throw it out. Not a big deal. But provide the docs on how to make the transition though. And if it’s so damn important, I’d like to see some other API changes. For example, creating menus is just not very convenient or intuitive, especially if you only need a single button. That could need some cleaning up too.

      “cocos2d is not as mature as the creator intends”

      That may be so. And that’s my other issue: what is everyone else thinking? When is it mature enough for most developers to call it a v1.0? Personally, if after v0.99 in February we hadn’t seen a single update since, I’d still be perfectly happy with it. Only exception being iPad and HD support but that was easy enough for others to figure out how to hack it in.

      Don’t get me wrong, my issue isn’t with breaking changes that might affect the book’s code, I’m prepared to upgrade it as much as I’m going to upgrade the Starterkit to keep it compatible. I’m mostly frustrated about the dragging on of the v0.99 throughout what feels like almost the whole year 2010. Most of what happened to cocos2d this year was maintenance as far as I’m concerned. If anything, this year’s cocos2d progress tells me that it needs two more full-time developers working on it (not necessarily all engineers, I see need for these two roles: a Product Manager plus Community Manager and a QA & Maintenance programmer plus technical documentation writer). Cocos2d’s popularity is so that you could easily pay the other two if you monetize it right while still keeping cocos2d itself free and open source. Cocos2d has become way too important for a lot of developers (and big ones, too) to be maintained like a single person’s pet project, and I fear that if it continues to be developed in this manner, it’s not going to be able to sustain its popularity all the way through v2.0, which we may be seeing in 2012? 2013?

      I’m saying this because I keep a close eye on the development of other engines, and quite honestly, if I look at Corona Game Edition I’m convinced and I predict it’ll steal cocos2d’s show by the end of next year if cocos2d can’t speed up its release cycles and features that set it apart (besides being free, and even in that area who knows if sparrow or some other cross-platform engine won’t catch up?).

  3. Mike Llewellyn says:

    I agree with the thrust of this post, and it does seem to me it is ready for a 1.0 version especially if it can have a better upgrade mechanism included as a result.

    Personally I have left all the updates alone on the basis that a 1.0 should be soon and then I can upgrade and separate out the Cocos2d library and do my admin then.

  4. daniele says:

    you are disappointed with speed of development of the main features or just with the number version used on it?

  5. horseshoe says:

    To be perfectly fair and honest, you seem to forget that cocos2D was some guy’s idea, who probably made it for himself and thought to share it with others in a “if this helps you, then use it…” way. since then it has become a widely used OPEN SOURCE library.

    Paul Gregory above makes some good points. Don’t forget now you have more of a vested interest because you are attempting to make money from it rather than use it for what it is.

    I just think your tone is unfair. If somebody started bitching at me about my own personal project and how it doesn’t live up to their standards or expectations, i’d kindly tell them to go f*ck themself.

    now, i’m very grateful for all the resources you make available to all of us GamingHorror, but I think you (as all of us) should simply be grateful that someone went to all the work to make a pretty great framework.

    Maybe your heart is in the right place and you just want to see a great product become better. In this case, now we know why programmers rarely become diplomats…. 😀 (um, yeah, i’m also a programmer….)

    • Your point is fair and square. Actually, I already got the “go f… yourself” message from the man himself. 😀

      Which also means I’m a little biased, and I’m definitely not going to be diplomatic, specifically not in this case. It pains me to see that cocos2d is now so popular and a lot of people depend on it, that I can only think it’s just neglectful not to bring its development on par with the demand. I understand, this is Ricardo’s pet project, it’s his baby, it’s his decision to do whatever he pleases – and that’s where I’m having a problem. I’m thinking he is no longer acting in the interest of the majority of developers. I’m grateful for his work thus far, but I firmly believe that his actions (or inactions in other areas) is hurting further development of Cocos2D and its community. Take the still abysmal state of documentation for one thing, and the loathing of product promotion for another.

      My vested interest isn’t so much in making money really. I don’t mind making more, and my ultimate goal is still financial independence, but I’m already more than halfway there. Another product would easily fill the gap. But my real investment is in Cocos2D itself, my experience with and my knowledge of it. I feel sort of limited by not being able to express and act on it how I would like to. Take Corona for example, if I were to use that for my work, they’re much more inviting to outsiders doing their own thing and essentially helping to grow the community. I have a number of things that I would like to change and enhance in Cocos2D, but the project isn’t really inviting to do that. You have to be on good terms with Ricardo and play by his rules (that he makes up as he goes along) in order to get a chance to do so. Besides, I think the project’s direction isn’t in line with my ideas, so once more it’s hurtful to see a project that I use and find very helpful go in directions that I don’t want it to go while other things that I find an absolute necessity are being ignored. Take the ability to easily upgrade existing cocos2d projects for example.

      Btw, I really don’t like it when people point out that Cosos2D is open source and free. That’s a fact, but it doesn’t change the fact that it’s also a business. Ricardo is living off of the products that only sell because Cocos2D is open source and free (and lacks documentation and good source code examples). Cocos2D is the thing that promotes him and his products, so the commercial aspects of Cocos2D are strongly intertwined with it, and you can see that in the forum where it’s really hard and in some cases impossible to walk the fine line between promoting other commercial products and getting banned. This again, is not in the interest of Cocos2D developers. They want to get informed about everything that may be of interest to them, not what Ricardo doesn’t like them to know about because he fears competition or losing sales. I have one word for that: paranoia.

      • daniele says:

        sorry again, but are you sure that for help riq’s project you need to have “good terms” with him? I don’t think.

        You have some advices\idea that want to be developed? so post in on the right section. If users like it. i’m pretty sure that riq will work on it. And moreover you can help to develop it.

        I think that the problem is on your side, because if you want to help, you can help. If you want to propose, you can propose.

        • Well, yes in my case I do think so. The whole idea of suggestions and proposals I get, and it’s the way it works. But that only works if you’re on the same level of understanding and you have a general direction in common. I can’t speak for everyone but I do know that there are other developers who also aren’t too happy with recent developments (or lack thereof).

          As for “1.0” just being a string, technically you’re correct. But I’m more worried about the implications. If someone were to evaluate game engines, he/she would rather go for a v1.0 and above. It’s also a sign of maturity. Sparrow has recently gone v1.0 in about 9 months, and they’re absolutely right in doing so. Cocos2D instead is 2.5 years old and still not v1.0. I know that some projects take a long time to develop, take Lua for example, it’s seen cycles where there have been 1-2 years between an increase of 0.1 in version numbers. But that’s mostly because the project has been very complete for a long time, and its developers (users) prefer stability over new features, especially because it’s been so widely adopted and used in projects with long development cycles (AAA games, embedded devices). So in the sense of widespread adoption, I understand a slower release cycle of Cocos2D, but not the fact that this isn’t the release cycle between 1.0 and 1.1 but between 0.99.4 and 0.99.5.

          I’ve also seen the changelog. I read it frequently. I also watch commits on Github and see changes made on almost a daily basis. I’m happy to see that there is progress being made and I appreciate his efforts, I really do. I’m also grateful and thankful for it. I just keep wondering how much of that is of relevance to whom?

          Let’s play a mind game: what have been the big improvements in Cocos2D this year that you (or anyone else) can name from the top of your head, and that are relevant to your work? I’ll start: HD/Retina support.

  6. daniele says:

    I think that riq do a nice work, he work well and quick (considering that he work solo)

    I no need a “1.0” version. i need a stable version. “1.0” is a string, i not interested on strings, but on project’s quality, and cocos2d is so nice.

    We use it for work and nobody has your impression.

    Why you speak about “few version” and not look the complete changelog?

    you ask for blog update? you can check yourself a daily update.
    https://github.com/cocos2d/cocos2d-iphone/commits/master

    you speak about unity,shiva,sio2 all not opensource project, and need a paid license, and moreover there are TONS of developers working on it,

    • My whole point revolves about “solo work”. Cocos2D is too big now to keep working on this solo, all the while other engines keep growing faster and better. I have high hopes for cocos2d-x though.

      Besides, with its popularity, I kind of expect the business aspects of Cocos2D to be taken seriously, so that developers can actually be paid to work on the engine. I’d like Cocos2D to get to that level, remaining free though but monetizing on all the by-products. Win-win for everyone. Especially a game editor would help immensely.

  7. horseshoe says:

    I’m quite content with what Cocos2D offers. It’s fairly easy to use (yes there could be much better documentation) and isn’t full of extra crap. It’s quite simple, straightforward, and geared towards developers who wouldn’t know how to build an engine themselves.

    I wouldn’t bite the hand that feeds you. :p

    Furthermore, the changes aren’t that crazy. I can still look at code examples before the classes were called CC… and still understand how to adapt those examples.