Fog Creek Software
Discussion Board




How often do you release your Software?

Hi,

I work for an ISV / Customised software place - I.e. we have a standard product that we also customise for some customers.

At the moment we release new software greater than 4-5 times per year, and as you can guess the quality isn't that great and some of the larger customers aren't too happy with having to upgrade their desktops that often. It also makes it difficult for us to schedule in required tasks such as updating the docs etc. (and testing).

At the moment we are trying to convince the management team that our software package, customers and the company itself has become too big to continue this pace. We are going to try and change to a 12monthly cycle with just the normal "patch" releases in between.

To us this seems more realistic than our current schedule, but I was just wondering what is the schedule some of you use? How often are FogBugz and CityDesk major versions released?

Thanks in advance.

Anonymous for this one
Tuesday, December 02, 2003

In our case, we support 2 versions concurrently.  We have a known stable release and a bleeding edge release.

The bleeding edge release goes to new clients and used in various situations.  There may in fact be several releases of this that we don't push out to all clients.  At some point (one/twice a year) everyone gets upgraded to the same level and the cycle begins again.

Almost Anonymous
Tuesday, December 02, 2003

Our major releases of our main product are never as often as twelve monthly - we usually have eighteen months as a target. We still have customers using versions first released in 1995, and which we ceased offering full support on pre Y2K...

Tim

Tim Sharrock
Tuesday, December 02, 2003

Agree with previous posters, here it is the same, between 12-18 months with patches coming out when needed. I'm happy with this cycle

anon
Tuesday, December 02, 2003

Usually releases are based on revenue. Are you
getting paid for each release?

son of parnas
Tuesday, December 02, 2003

We release once a year with patches in between as needed. We support the last 2 full releases.

coresi
Tuesday, December 02, 2003

Four (at least) senarios: 1) regular releases made for "upgrade" revenue; 2) regular releases so support contracts look like they are worth something; 3) regular releases made to make the product look "fresh"; 4) release whenever it is necessary to upgrade.

Except in rare and obvious situations, there really is no engineering purpose to regularly scheduled release. Releases "only" need to be done when there is really something to release. The "other" reasons are marketing justifications.

Frequent releases (especially for stable, mature products) are annoying and expenseive for end users.


njkayaker
Tuesday, December 02, 2003

If you are talking about a single application with no other dependacies, then yes, there is no (engineering) reason to have regularly scheduled releases. If your product relies on other applications or is depended on by other applications, this is not true.

Eg. If I write an application like SpamBayes that works with MS Outlook, there better be a new version scheduled when Outlook N+1 comes out.

Likewise, if you are company producing Outlook and someone is planning on building an add on like SpamBayes, you better tell them when to expect the new version.

pdq
Tuesday, December 02, 2003

"Frequent releases (especially for stable, mature products) are annoying and expenseive for end users." - That is exaclty what we are finding now njkayaker, previously we had smaller customers (and a smaller amount of customers), but now customers don't like having to reinstall an application on a server and 4000 desktops. They have to schedule outages and these can be difficult when it is one of the organisations SQL servers we are talking about.

Also, for the most part the 5 upgrades a year are just for the maintenance contract to look like it is worth it. But every upgrade, rather than being a patch (or upgrade) they require a reinstall of the database, and all desktops. We are going to try and bring that down to a yearly release (government regulations to keep up with in our software) - but for the other 5 releases because they aren't really giving anything to the product (but are still compulsory installs) we would just cut them down to an as needed patch release that could use an auto update mechanism that we have written already.

And also it is becoming our experience that the bigger customers demand to know exactly when new releases are going to come out and what they will include so that they can decide wether they want to install it and to schedule the appropriate downtime windows for their network.

But 12-18 months with patches in between was exactly what we were expecting to here.

Anonymous for this one
Tuesday, December 02, 2003

Quote from pdq: "If you are talking about a single application with no other dependacies, then yes, there is no (engineering) reason to have regularly scheduled releases. If your product relies on other applications or is depended on by other applications, this is not true."

(I _did_ indicate that there might be other senarios). While the upgrades of a dependent product will follow the upgrades of the (independent) software it depends on, the release policy driving the independent software also implicitly drives the release of the dependent software. (Thus, my classifications still stand.)

njkayaker
Tuesday, December 02, 2003

To Anonymous for this one:

(If your smaller and fewer clients had any sense, they would have been annoyed too (sarcasm).)

Consider making the software installable on a LAN. If your clients have a competent LAN, it might make more sense to install the software in one place rather than on individual PC's. It's possible that your installation is more complex than it really needs to be.

njkayaker
Tuesday, December 02, 2003

Another thing. If your company chooses to continue the too-many-releases-in-a-year approach, make sure subsequent updates don't require that earlier updates need to be performed. Then, you can tell your customers (something like) "If you need feature X of this update, install it. Otherwise, you can wait until the (presumably) obligatory annual update." That would be smart and considerate.

njkayaker
Tuesday, December 02, 2003

Yes njkayaker, we have recently changed our install process and this next release we are doing will be the final "compulsory" install - it used to be too complex. But thanks to everyone else for their opinions as well. (I wasn't really looking for answers, just opinions).

Anonymous for this one
Tuesday, December 02, 2003

Our software isn't released - it escapes, leaving a trail of bloody testers in its wake. We relish the wailing and gnashing of our customers' teeth!

KlingonSoft
Tuesday, December 02, 2003

My company sells software on the basis of a yearly subscription.  Customers run an Update Center that downloads the latest-and-greatest changes.  Database structure changes are performed automatically during this process, and they upload their Error Logs in the same swoop.

That being the case, we distribute enhancements and bug fixes every two to four weeks, as needed.

1/4 Ain't Bad
Wednesday, December 03, 2003

Its not how often, its how ready that's biting you in the ass.

If you'd look at what features you want to have incorperated a year from now,  you can build those into an alpha version at first, do internal testing, then give it to the clients that need those new features, as a beta. Then after they've noticed more bugs, fix those, and call the beta your new real version. You don't have to send every version to every one of your customers, and all the alpha's and beta's and somesuch are often enough to get the marketing folks to calm down. Generate slick new manuals etc, for the release version only, give email documentation for the alphas and crappy printouts in addition to last version's slick manual's for the beta.

And DON'T send your software to the suit. Send it to the engineer/IT department that will be installing and using it.

This approach benefits heavily from the ability to hide new/partially implemented features in a codebase. However it works quite well and I've seen it several places that I've worked, including my current one.

Micahel Langford
Wednesday, December 03, 2003

*  Recent Topics

*  Fog Creek Home