Putting up a release is a fine art. This might sound cheesy, but (believe me) sometimes it really is.
“Are we doing it too early? Or, is it too late?”
“Have we fixed enough bugs, to justify the upgrade hassle? What about enhancements and new features? Will the costumers be willing to upgrade?”
“Oh wait, a costumer just reported one extremely exotic bug. Hold the release! Hold everything for a week or so, until we cover it, and then we’ll lunch…”
This are just some of the troubles a new release may cause. We have struggled with it at first, and with some of it we still are, but somehow we managed to deal with releases.
Our process of making release related decisions are developed around the fact that we sell installable web application. Despite web based services such is Basecamp or BlinkSale, with installable software such is activeCollab things are a bit different. You need to download the installation package, unpack it, upload it to your server and run installation script. Similar process needs to be done every time you are upgrading the system – download package, upload updates files and run upgrade script. Although we work really hard to make installation and upgrade process as easy as possible, this can sometimes be really tedious, especially when new versions are published frequently.
Because of that we try to ship improvements and new features, no matter how small they are, at regular pace, while not overwhelming our customers. From experience with developing and maintaining a product, one update that improves stability, fixes bugs and brings smaller enhancements in 1 – 2 months is OK. A lot of attention needs to be devoted to making these increments as stable as possible and to keep them simple. They include just the small things, nothing more. If we would to try to put more in minor release we would put stability in jeopardy and might introduce some new bugs.
Major upgrades a different story. They are far less frequent (one in 9 – 15 months) and usually include a tone of changes. These release are designed to deliver a lot of changes and keep the need for constant upgrades as low as possible. Amount of code change is huge, so a lot of testing is required, but end result is worth it. Just look at activeCollab 2.1

Putting up a release is a fine art. This might sound cheesy, but (believe me) sometimes it really is.

  • “Are we doing it too early? Or, is it too late?”
  • “Have we fixed all of the bugs, to justify the upgrade hassle? What about enhancements and new features? Are  the users going to be willing to upgrade?”
  • “Oh wait, a costumer just reported one extremely exotic bug. Hold the release! Hold everything for a week or so, until we cover it, and then we’ll lunch…”

This are just some of the troubles a new release may cause. I had dilemma like this at first, and still have some, but me and my team managed to deal with releases, in our own way.

Process of making release related decisions, at a51, is developed around the fact that we sell installable web application. Unlike web based services like Basecamp or BlinkSale, with installable software such as activeCollab things are a bit different. You need to download the installation package, unpack it, upload it to your server and run installation script. Similar process needs to be done every time you upgrade the system – download package, upload update files and run upgrade script. Although we work really hard to make installation and upgrade process as easy as possible, this can sometimes be really tedious, especially if new versions are published frequently.

That’s why we try to ship improvements and new features, no matter how small they are, at regular pace. Speaking from my experience with developing and maintaining a product, one update that improves stability, fixes bugs and brings smaller enhancements in every month or two is OK. A lot of attention needs to be devoted for making these increments as stable as possible and keep them simple. This includes only the smaller adjustments, nothing else. If we try to put more in minor release we would put stability in jeopardy and introduce some new bugs. That’s why simple and small upgrades are marked with the third figure (for example X.X.2.)

But, major upgrades are whole different story. They are less frequent (one in 9 – 15 months) and usually goes with a Beta testing period before releasing the final version. These releases brings big improvements, new features and freshness into a product. Besides all the hard work, hours of testing and lines and lines of code written, there is no better feeling then seeing a new number in your products name – like activeCollab 2.1. And, if the feedback is good (as it was with activeCollab 2.1.) then you know that it was all worth it.

Then, once again, the story goes back to the beginning – a new set of smaller fixes and upgrades will be released, and the cycle repeats. By now, we have released two smaller upgrades in 2.1. branch – activeCollab 2.1.1 and activeCollab 2.1.2. and keep on working on a next small, bigger and big release, enjoying the process.

So, if one asks me: “How frequent software updates should be”, my answer is: “Small enhancements and bug fixes should be released once in every month or two; when it comes to the bigger improvements, one in six months will do; and major releases should be published in every 9-15 months, with a new and refreshed features.”