views:

552

answers:

18

Is it frowned upon to release your software with a version number high than 1?

For example, some non tech-savy people might see a competitor's product with a higher version number as meaning my software is not as good.

+4  A: 

Oracle did it with their first DB release. There was no Oracle 1.

What you think of the quality of Oracle's software is a different matter.... :-)

cagcowboy
Heh, bang on on their quality.
hectorsosajr
Watcom did the same thing with their C/C++ compiler. The first version was called version 6 because Microsoft and Borland had released version 5 of their compilers around the same time.
Graeme Perrow
Why not ace it by releasing version 77 straight away? You beat the competition by tenfold!
icelava
The first release of Windows NT was 3.1.
DGentry
A: 

You could use the year of release, or a fancy codename instead of a version number, thus bypassing the ethical issue of artificially making your software seem more crufty than it actually is :)

Marketing has a lot to answer for.

JeeBee
A: 

I say yes it is unethical to artificially inflate the number to your advantage. It is, however, perfectly fine to call it version 10.0 X .1!

brian
+7  A: 

I would be miffed by anyone who set their version number based on marketing, rather than software engineering, considerations.

The reality is that having more releases, or patches, or a higher version doesn't make your software any inherently better, just as how having more eraser marks doesn't make something written in pencil any inherently better.

What marketing wants to call the product, I don't care, and in fact, I'd prefer that they didn't latch on to version numbers. Which Microsoft has gotten well, because while their internal version numbers remain somewhat consistent and sane, marketing doesn't push "Windows 6" but rather "Vista."

Daniel Papasian
You are a programmer. I seriously doubt the average computer user would be "miffed" or even notice if a product had marketing version numbers. To them, all version numbers are marketing.
Simucal
I would prefer that marketing didn't use an engineering-derived version number, but I would demand that they didn't influence engineering version numbers. As a programmer, I care about others' version numbers- these are what are exported via API documents, file formats, etc.
Daniel Papasian
A: 

I really don't think it matters at all. I don't know anyone, even those who aren't tech-savvy, who would assume that Version 2.0 of product A is even remotely related to a Version 1.0 of a product B.

The really non tech-savvy people probably won't even know what the version number is for a piece of software they have/want.

17 of 26
The people who don't know what a version number is, is the people I'm afraid of :)
Brian R. Bondy
A: 

I think that it's all in the marketing department to sell the product to interested parties, however the version number should be accurate, although how you define the version number might play into things.

Thomas Owens
+1  A: 

I wouldn't worry about it. Let the quality of your software speak for itself. Stick with 1.0. Or, even better, don't attach a version number at all. If someone wants to know the version - well, that's what Help / About is for. =)

Erik Forbes
+1  A: 

Either way people are going to know it is version 1. If you call it version 2.0 but version 1.0 is no where to be found, and no one has ever seen it people are going to figure it out.

Alternatively you can version internally and just call your product "Amazing App better than XYZ 2008"

Edit: Actually I changed my mind, call your software Amazing App 2010. That way people will think it is from the future.

Jack B Nimble
+4  A: 

A simple solution to this is to release the first couple version with year numbers (current year, or coming year), or model names. That is kind of in fashion right now anyway:

  • Delphi 2009
  • MS SQL 2008
  • Windows Vista
  • Microsoft Office 2007
  • RemObjects Oxygene (which came after Chrome and Joyride)

Although individual version numbers are still more common.

This avoids the question of "Where is Version 1?" without having a version 1. After a few releases you can switch back to version numbers if you want, and be at a respectable number.

You can also go away with version numbers all together and sell your software on a subscription basis, so a purchase includes updates for a year, and then you can give them build 20080925A (build date), and update them frequently to the latest certified build.

It really depends on what kind of software you are releasing, how you are distributing it, and your target market.

Jim McKeeth
A: 

Let me turn the question back on you: would you rather buy version 1 of a big, expensive software package or version 3.14?

The purpose of the version number is to be a unique handle for debugging and troubleshooting. It also communicates something to the users. But the first use is irrelevant to the second use. If I use version 1702 internally, there's know way to say whether it should be released as version 1 or version 11.

Jon Ericson
I'd buy version 3.14 because I like Pie ;)
Otherside
I like rounded Pi, myself.
Jon Ericson
+2  A: 

I'd actually be more inclined to keep my version numbers lower than my competitors', so my marketing people could say "Our version 2 is equal to their version 10! They took 10 releases to get this far, and we made it in 2! Our people are therefore 5 times smarter! Give us more money!"

(This is why I don't have, or ever want, my own company.)

Adam V
A: 

Sure, you should call it version 1. But there's no rule on how quickly after that you can release version 2!

Mark Ransom
+8  A: 

I believe there are 3 major ways people market product versions:

  1. Product Name [Version #] (i.e. Wordperfect 5.0)
  2. Product Name [Release Year] (i.e. Gentoo 2008.0)
  3. Product Name [Code Name] (i.e. Windows Vista)

I actuall prefer the release year as part of the versioning strategy, it lets your customers know what the latest version of a product is, general age of the release and using the 2008.1 type of number, you know the release is a revision (i.e. Service Pack).

If you still decide to go with a version number, I see no harm in starting with 1.1, that is what we always did at my old place of employ...

Redbeard 0x0A
Not only that, but as the software ages they feel the need to upgrade simply because they know, every time they reference it, that they're using Office 1997, for example. Great for upgrade encouragement! Although even better is a message on the splash screen, "Version 2008 is available now!"
Adam Davis
This can backfire if you don't plan on making annual releases.
Erik Forbes
You don't have to make annual releases when using the Release Year scheme, however you do need to make releases every so often (dependent on size, think MS Office). I have seen companies operate on 6 month release cycles and 1 year release cycles, this would be a good instance to use the year.
Redbeard 0x0A
+2  A: 

For our software we used version 1.0 and 1.1 internally and never released them to the public. Our first public release was version 2.0. No one was upset and if anyone asked we told them about the internal version.

Jim C
A: 

WordStar 1986

+1  A: 

My company regularly has this argument with the engineering department. There was a huge explosion when we tried to label our next release a major version above the previous one, because marketing/sales thought our current customers would be upset that we have a new major version so soon and they need to upgrade. They wanted it to be a .5 release higher than the previous one. We went back and for this a few times... currently, engineering is winning. The marketing department also uses releases numbered by year as the names of the product, so I don't know what the fuss is about. We tend to mix our internal and external names for things a lot though. Also, when we started using version numbers of the current format, we started at a fairly high number for exactly the reason of fear that customers would think our software isn't as good as competitors with higher version numbers. This is a real problem, at least in marketing's heads.

My $0.02 is that the version number should reflect major features/changes of the product, and thus the first public release is by definition 1.0.0.

rmeador
A: 

I am a big believer in:

[major].[minor].[sub-minor/patch]

Where for beta [major] = 0 and for gamma [major] starts at 1. I think it's the most informative, easy to understand, and honest version numbering scheme.

Of course, for alpha I'm a fan of the simpler: [svn-revision-num] since it's only for internal use at that point and that's more informative.

sgibbons
+1  A: 

No, absolutely go ahead and start from an arbitrary point. Alternatively, use a vaguely defensible scheme like the last digit of the release year.

Marcin
I agree fully. A high version number can easily be justified with an excuse.
Brian R. Bondy