* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Version numbering. Major updates.

I number major updates by changing the second number is version: 4.7, the next major update is 4.8 and so on. It was like this for years.

Recently got several e-mails from customers, who complain that update is not major because "it's only second digit changed therefore it doesn't look like the update is major" while they noted that change list definitely looks solid: http://www.djsoft.net/enu/news/75.htm

I'm starting to think that people would like to see larger version numbers. Eg. version 4, then version 5, etc.

Problem is, they asked "is this update a major?" and after I said "yes", they paid for it :) I don't know how many people who didn't ask and didn't pay because of it...

The trend with FireFox, Chrome and many other popular software is so called "version number inflation"... Version 22, Version 30 seems OK nowadays.

Should I change version numbering scheme? Would it be an additional reason for people to purchase updates?
Kuzmitskiy Dmitry Send private email
Sunday, July 28, 2013
It is standard to only charge when the first digit changes. It is what most people expect, so I suggest you do that. Changing the first digit more often also has the effect of making your product look more mature.

I also recommend:
-give charge anyone who just purchased to upgrade (3-6 months grace is probably about right)
-don't charge people for upgrades more than once a year (18 months to 2 years is probably about right)

Another approach is charge maintenance yearly and give free upgrades during the maintenance period.

Whatever your policy is, write it down on your website.
Andy Brice Send private email
Sunday, July 28, 2013
It sounds like the objection here is that point releases are incurring a charge, which is not standard practice and would come as a surprise to me. There's no law forcing you to do this, but it's definitely established practice.

Perhaps you should then change the big number at each yearly release, and have some bug fix point releases in between those big feature releases.
Scott Send private email
Sunday, July 28, 2013
Hm, so 4.8.0 was released in December, and 4.9.0 in May. And indeed, 4.9.0 has many new features.

It sounds like you are a very fast developer. That is probably part of what is confusing to customers.

I think that after each purchase, there is an expectation there will be a 1-2 year period during which the updates are free. Generally these are point releases.

Major new versions that require an upgrade fee every 5 months would be annoying to most users. Maybe that could work if the fee was particularly modest, then it becomes sort of like a subscription. Or switch to the normal method of integer releases every 1-2 years, and free point releases in between.
Scott Send private email
Sunday, July 28, 2013
Thanks everyone for responses!

I don't charge for major releases  - they get 1 year of free updates on purchase, so fast releases are not a problem.

But sometimes people don't want to prolong their 1-year update subscription - instead, they wait until "major" version is released.

It looks like second digit change doesn't sound "major" enough. Now I'll try to release a true major version once a year :)
Kuzmitskiy Dmitry Send private email
Sunday, July 28, 2013
+1 one to the first number changing being the accepted "charge for update point".  I offer one year of free upgrades, and yearly maintenance.

Thus, when I have a new major release I give anyone with current maintenance or who has purchased in the last 12 months a free upgrade.  I've had almost no complaints from people who had to pay.
Mark Nemtsas Send private email
Sunday, July 28, 2013
Changing the 1st digit at least once a year sounds sensible to me. We laso offer free upgrades for the frst 12 months after the purchase date, but users are reluctunt to extend it unless they see the 'major upgrade'.
Marshall Trevis Send private email
Monday, July 29, 2013
We have a simple rule: a renewed support contract commences from the date on which the previous contract has expired. So late renewals == shorter support periods.
Dmitry Leskov @Home Send private email
Monday, July 29, 2013
Quite the contrary on my side.. Our users are taking updates more frequently than they would take a minor or major increment. It depends on the nature of the product. If at the point of purchase I was fully satisfied with the software, I'd be very reluctant to take the minor or major upgrade myself but will always grab the bug fixes. In B2B this is more vivid, upgrading software is not a click of a mouse, it may involve lots of people and can do more harm than good if things go sour which they often do. So, what I do is regularly post updates even if there are no bugs reported, there are always things to improve. People see the steady pace and they get used to your rhythm eventually. Minor increments go at least once a year with new set of features collected from the feedback. Major upgrades are always pre-anounced and mentioned many times before it hits the news. I tend to do this at least 6 month before the release. And even after major release the previous version is still fully supported for a while. I often see customers with couple of years old versions in production but still paying annual maintenance plans and then jumping several versions forward when they decide it's the right time. Quite logical, I'd do the same..
Dima Send private email
Tuesday, July 30, 2013
@Marshall Trevis
"users are reluctunt to extend it unless they see the 'major upgrade'."

That's exactly what I'm seeing :) I'm staying with versions 4.x for 3 years already... I think I can increase income generated by updates by changing the first digit.

Thanks again everyone - now I know what to do next :)
Kuzmitskiy Dmitry Send private email
Wednesday, July 31, 2013
I've always followed what I was taught years ago in a style guide: 1.00 for initial release, then 1.01 for small updates, then 1.10 for a large update, and 2.00 for a total major change or overhaul.  It's honest and reflects the amount of change.
PSB136 Send private email
Wednesday, July 31, 2013
I agree, I think you have to increase the version number. Most companies use the decimal as an update, so the perception is that it's an update.

That being said, we're running into an issue ourselves. We do year.month as the version number. The problem with this setup is that if you go more than 2 years, say 2 years and 1 month, without a major release, you skip 3 version numbers...
Stephane Grenier Send private email
Wednesday, August 07, 2013

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz