Friday, 11 March 2011

Soul of a new release!

Fun day as ever, and been working, yet again, on trying to get a stable new factory release of the code...

The problem is that I want what ships with the product to be the "best you can get", obviously.

That is, of course, the latest code I am working on right now....

Sadly the latest code I am working on now also has the latest bugs I just added to the code. Sadly I don't know of these bugs, as, well, I would fix them if I did, obviously.

Writing new code is not really coding it is enbugging... Where else do bugs comes from?

So what happens is we make checkpoints - code freezes - and so on - and make a factory release candidate. I have done a few in the last two weeks! naturally this needs testing in the field as well as on the bench as much as possible, for many days at least...

During this time you find things. Now, if it really is totally cosmetic, a typo, then no need to re-issue a factory release candidate and start again. But what if it is something missing - something minor for which there is a simple work around? What if something not technically correct? Something just a few customers will notice? And what if this factory release is better than the last anyway as these are not new bugs? Arrrrg!

Where do you draw the line. Oh! the life of a perfectionist!

Well now, I have worked though about 5 release candidates and damn well this one will be a factory release. Unless there is a total show stopper it is happening. I don't mind doing a replacement next month, but it cannot go on any longer...

And its name is Marmaduke.

4 comments:

  1. Good luck!

    Spinning around the -rc cycle can be one of the most frustrating things, but it's also one of the most satisfying when you finish with something that you're happy with.

    There will always be bugs so releasing is all about risk and limiting it in the areas that you deem to be most important.

    Don't forget to check that the "in-the-field" upgrade procedure works perfectly otherwise all bugs are final. :-)

    Good luck!

    ReplyDelete
  2. Indeed - it's not as if I am new to this either :-)

    The field upgrade stuff is fun too. We have been very careful that crashy software auto reverts to old code, and that has saved our bacon on test boxes a couple of times as I am sure you can imagine. Catch it software can not always self diagnose all bugs...

    What is fun here is that we are auto-upgrading by default on the 2700s this time. It may not stay like that, but at these early stages makes a lot of sense, and this will be the first real life test of that...

    Found one bug so far, but it is an un-necessary extra un-documented and ignored attribute in the config. It may cause a query or two but no harm, so no reason not to delay making Marmaduke a factory release, yet!

    ReplyDelete
  3. Cool!

    Why not add some meta data to the release package so only a controlled percentage of boxes autoupdate at a time?
    Perhaps you could key it off of serial number or something and then you could do a controlled release and get an idea of the statistical differences in the failure-profile compared to the previous software.

    ReplyDelete
  4. They already spread out over 24 hours, so the idea is we can cancel a release at the first report of problems.

    ReplyDelete