Do Software Versions Really Matter?
An anonymous reader writes "I work for a rather large software company and I am currently working on a completely new product. So new in fact, that the official name has not even been decided. I had assumed that the version number for this product would be 1.0 (at most). However recently I learned that the Product Managers want to release this NEW product with a version number somewhere between 5.0 and 8.0 because 'there is a stigma about buying 1.0 products. People assume it's no good.' This latest Dilbert-esque comedy routine nearly sent me over the edge. So to gauge my sanity against that of the upper Product Management, I ask the community: Do version numbers play a role in software decisions, or have product version numbers lost all credibility and meaning? Would the community feel comfortable buying version '6.3' software (and paying tens of thousands of dollars for it) knowing that it was the first release of the product?"
Let me know when you hit 7.0
Personally, I take to opposite view. If I try an application labeled something like version 6.0, for example, and it still has a lot of bugs in it then I'm likely to be a lot more pessimistic about the software. After all, version 6 software ought to have most of the bugs worked out by then. I would think poor quality at version 6 would reflect much more negatively on a company than at version 1.
We've all been conditioned by a source that will go unnamed for now that version 1 software is probably full of bugs, so it's not unexpected. It's also probably true that some people will avoid software simply because it's version 1. Yet, it's the same software whether you call it version 1 or 6, so it has the same bugs in it (e.g. the user who tries the software will experience the same problems, regardless of the version label). For a company to risk losing the good will of the customer on a marketing gimmick seems foolhardy to me. Trust is easy to lose, hard to regain.
The NSA: The only part of the US government that actually listens.
Turn it up to 11!
Why use software X version 1.0 when I could use software Y version 6.1?
Some people just see the bigger number.
That will inspire confidence in quality...
Just look at warty warthog.
Most users won't even notice the version number unless you put it in the face. Just call it FooBuster and put the version number in an about box somewhere.
I do research before purchasing any software, if I will Google for your software and will not see any references to past versions I will not purchase it.
A lot of us are probably using Open Source software that's been released and relatively stable for years but is still only at version 0.2.07 or somesuch. We're not exactly representative of the general public.
Avoid anything that has any major version number followed by .0 once a product hits x.2 or x.3 it should be fine...
Service Packs have jaded me :)
Not the actual version number. Anyone with real IT experience will know not to touch .0 releases in a professional environment, regardless of vendor.
See: http://news.cnet.com/8301-10784_3-9814858-7.html
When Oracle began selling its first commercial SQL relational database management system in 1978, which version was first officially released?
A: Version 1.0
B: Version 2.0
C: Version 3.0
Answer: Version 2.0. There was never a 1.0 version. Said Ellison: "Who'd buy a version 1.0 from four guys in California?"
This is like the one where they had to rename the movie "The Madness of King George."
Americans, the story goes, wouldn't be interested in "The Madness of King George III" because they missed parts I and II.
Way back in 1995, I upgraded my version of Windows to Win v95 from Win v3.11. I thought "oh man, there's been 92 upgraded versions of this software! I better get with the times!"
The Internet is generally stupid
If there's a version 6.3 of software in my field that I've never heard of, I generally assume it's some crappy shareware knockoff of what I'm already using.
If it's version 1.0, I want to see what was so important that they had to make a new piece of software (which is why I tried out Google Chrome).
I have seen purchasing decisions based on version... but usually it has less to do with what the version number is, and more to do with how long the version has been on the market. If a version 1.0 was just launched, unless there was a large business case for taking the risk of buying it, the company I work for would wait until 1.1 (or until 1.0 had been on market long enough to prove itself stable). Same goes for upgrades, a new release of a product is not moved to unless there is a large business case for the move (or the version has been on the market long enough).
What's long enough? Depends on the vendor and their release cycle.
I mentioned tinker-toys once in a post - now I'm modded down for life.
Over the past five years, Version 9.6 became 9.7 with no real updates. 9.7 jumped to 10, and then 10.2 with no real updates. Then it jumped all the way to 15.7 with no real update. Then came version 16.0, with no real updates. Next month I can look forward to version 16.2! I'm not expecting any real updates.
Just call it "_________ 5000" and it'll be a while before it starts to sound outdated.
Your employer basically just admitted to you that they're trying to deceive and mislead the customer.
The reason people feel more comfortable with higher version numbers is that they assume the code is more mature at version 5 than the first cut would be at version 1. Anyone with a serious interest who heavily depends on the software will see past this and look into the history of the software, especially where large amounts of money are changing hands to aquire the software. Your company on the other hand is hunting for schmucks who'll give them money without doing proper research. Not a good sign. That is not how you gain long term customers and cement a relationship that will result in further sales and on-selling. Your sales/marketting people probably already have their CV ready. So should you.
These posts express my own personal views, not those of my employer
It's standard practise in the world of proprietary software and spin. The act of releasing software with its actual version number is a uniquely open source thing.
It even extends to hardware. When I was laying out circuit boards, my employer insisted that the version numbers on the PCB be incremented or obfuscated.
Just remember the same management that throws out this wacked out theory is a parallel of the management that will be deciding to buy the product in question. I would throw back to management how they are going to answer questions of details if you do up the number, to say version 3 or 6 as to who has actually been using the product and what the user base is up to. Really you can attach any version number you want, but anyone doing due diligence will get by that number and realize they are one of the first to buy your product. So you can either poorly BS, or just realize someone has to buy it first and be honest from the get go. Unless of course management choose to be atypical corporate and make up details and customers to back up how the first version of your software has a fabricated stellar history to sell more to those uneasy about being the first ones on board.
Of course, theirs tells you when it was released, seems to takes most people a while to figure that out, myself included.
There never was a Dbase I version, their initial release was Dbase II. :)
Who pays attention to version numbers on anything nowadays? I don't they've all because ridiculously named and hard to keep track of, ME, XP, 2K, MX, CS1/2/3/S, Gusty Gibbon, Feisty Fawn, Hoary Hedgehog etc etc.
What happened to the good old days when it really was just simple version numbers?
Can I leave this box empty?
This becomes a multi-headed issued.
Yes, numbers generally are not needed or meaningful except to say "this is more resent than that". So starting with V08 is not a problem since V08 could mean 2008.
Does your company have other software that is *MUST* work with this software?
If yes - the numbers can matter. It is easier to keep compatibility, if all software has similar numbering systems. Look at VMWare were each has it own numbering system - how do to tell easily that X V1.5 works with Y V3.5.
Think about taking your company into dropping numbers for years or V08. This makes a better case of aligning one product with even other companies' products. Such MS Office 2007. ;-)
It really depends on the type of software and the target demographic.
This is a sig. It is like every other sig in the world, except that it is mine, and it is different.
Version numbers have lost a lot of their meaning. We've been on version 2 of my company's product for something like 6 years. We just keep on increasing the minor and subrevision numbers.
Personally I think it's sort of crazy. The version number inevitably ends up being obsolete in no time. FireFox was just released and it's already 3.0.3... but no one is going to call it that. They're just going to call it FF3. I think the same holds true for pretty much all other products.
You should just compromise and version your product using the year it's released and then just attach a build number to it based on the date. If you actually plan on releasing significantly different versions during the year you can follow the lead of the component design firms and do something like 2008.1 (or 2009.1 if you won't be releasing this year).
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
I'd agree there's definitely the potential for a "$99-style" psychological effect of labeling a software product "1.0". However instead of outright lying about how many versions of this product have actually already been field-tested, I think it is more elegant to completely remove the version number from the product information and marketing, instead just leaving at most a build number in the Help/About dialog.
would be to take the 4.5.1.2 version and rebuild it from scratch to a new 1.0 version where all the old cruft is removed.
Windows 7 is actually the .1 release of the third version of NT. (No wonder they finally gave up and just called the next version "Windows".) But then they started the NT line with the first release being "3.1".
Going back in history, dBase II was actually the first version of dBase. For just this reason: no-one trusts a 1.0.
In open source, it goes the other way - the project has to just about take over the goddamn world before they'll admit it could possibly be a "1.0" release.
Summary: version numbers are marketing just like everything else.
http://rocknerd.co.uk
people who are stupid enough to buy software based on the version number rather than research if it is quality software.
Now that I think about it, that's our entire purchasing dept...
New Marketing decree:
From now on all revisions will be released as version 7!
Just call it what it is -- the internal version can be 1.0.0.3 or whatever, but the version on the box and in all literature can be Version 2009 (or the year of release). That was popular about 8 years ago...and still works too!
Maybe that is the reason they didn't name it an Xbox 2, when there is a Playstation 3 out.
God spoke to me.
No, major version doesn't matter. What most people feel afraid of is .0 releases - always start your public releases from .1 version.
Software versions matter because they let you know what's older and what's newer, but that's about it. Case in point: I'm trying to get the Network Block Device client/server setup working on an embedded device running Linux 2.6.26. The client part in the kernel is incomplete if you want to try using it for swapping (but that's another story). The versions of the NBD client (and server kernel patches) range from 2.0 to 2.4, but these have nothing to do with the version of the kernel. It's confusing as hell.
What you're proposing simply won't work, and carries a huge risk of making you and your company look dumb. Also, without a plausible explanation why your 1.0 is actually labeled 6.3, the customers, sales force, and techs are all likely to make up their own. Many of them are not very appealing:
A) We actually stole it from a competitor and kept their version numbers
B) We went through six major version changes before arriving at a marketable product
C) We have been selling this product to a different market, under another name, for years
The '1.0' moniker is a label. It carries with it the meaning that something is new. Remove that label, replacing it with one that means something is NOT new, and people's minds will invent the reason why.
Unless of course you come up with a good story and get it straight ahead of time. This is well known as a basic tenant of dishonesty...
The quality of the software is what matters. You should be working with a small number of smart customers that accept running the product before it released to give you feedback. By the time you ship the official first version it should be rock solid and you should have testimonials from customers that have been using it in production for some time. We show customers something as soon as it is wiggling. They tell us what is wrong with it and we loop until we have something useful and they start asking "when can I have it?" or better yet "give it to me now, I don't care if it is not "production." When we have something we believe is solid, we start charging money for it. I bet your product managers also want to ship it before it is solid.
more cowbell
- Release it as a beta, and never let it out (Charge for the "beta.")
- Use the year as the version
- Use a chemical element or gemstone as the version
- Use an animal as the version.
- Use two random consonants.
- Periodically drop the most significant digit
You have a lot to learn about business. As a Software Engineer, your best approach would be to make software products that your company can sell. That means you listen to sales and marketing, and anyone else who knows what its like trying to shift copy on the ground. When they say you have to release as version 6.3, that's what you do. If 1.0 doesn't sell, you're out of a job.
It's misleading and a clear fabrication. I can understand not wanting 1.0, but why not keep the version number off altogether? After all, you don't really have a 'version' until and unless you come up with an update. I believe customers do pay attention to version numbers. Not that '6.0' guarantees anything, but it implies a product that has been around awhile, been accepted for awhile, and that the company has not turned its attention away from it and updates, probably based on customer feedback.
Bad karma from this: Class Action suit.
How about a moderation of -1 pedantic.
If I see a version-greater-than-one of something, I'll take a look at the change list and see how quickly new features get added, or bugs get resolved.
So if I see a high version number and no history, I see a scam.
I don't go for scams. I prefer to report them to the local authorities.
If a prospective client sees "New Software version 7.4!" and does a search to see what people thought about previous versions it will only make you look shady.
Anyone who's encountered Linux should know that version number is irrelevant most of the time. One of my favorite programs is version 0.1.6, does that mean it's not even remotely stable?
I have had a similar problem. We had a numbering scheme all worked out with much discussion back and forth to clarify with examples of how it will be used. All of the managers agreed. When it was nearly implemented a BA thought it was too complex (major.minor with an optional letter for patches, pretty standard if you ask me) so we now have a major release 10 or 11 times a year.
How does the new 48.0 version work? Naw, lets wait 6 weeks for 50.0 to come out.
6.3 will be the number of weeks it spent in development; the number is truly relevant and honest so you should feel good about it.
Two different version numbers - the marketing version number can be used to help customers differentiate between iterations of a product. The development version is generally used internally to differentiate between feature sets.
That being said, using a version number for marketing is probably not very creative. Use something more expressive like ProductName YearReleased (i.e. Foo 2008), which lets the customer more easily distinguish which version they want (perhaps 2008a, 2008b for major patches). Or just come up with a different creative name for each iteration (perhaps with an optional version number to help new users who don't know your names yet) ala Apple.
Read: http://www.slackware.com/faq/do_faq.php?faq=general#0
If they really want to start at > 1 then at least talk them into something with meaning, try an abbreviation of the year. For instance start at version 8 if you release this year. Have 8.1 for a follow up released this year. This way there is a justifiable reason if your customs question you on it and the number actually conveys some meaningful information.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Windows 7
If the software costs tens of thousands of dollars anyone doing due diligence is going to look for reviews of earlier versions if the version number is greater than 1.0. When they find out there aren't any earlier versions, what are they going to think?
Why not just use the year? -- (tv salesman voice) "All new fobar_soft(tm) 2009! Supplies are limited! Get yours today! If you order now, you also get..."
(just finished up on Mudbox 2009 aka V2.x :-), so this hits close to home :-)
Ian Ameline
I remember long ago when Slackware jumped from 4.0 to 7.0, not because there had been 3 major revisions that just hadn't gotten released or something like that, but because Red Hat was already on 6.0 and Patrick Volkerding was tired of being asked why Slackware wasn't at 6.0 yet.
To answer the original question, version numbers don't mean much. They can give you an initial clue, but you've got to look at the history of the software to know the truth. Sometimes there are huge version jumps just because, sometimes there are major changes but only a change to a minor revision number.
Jumping straight to 6.0 seems a little strange. Especially since no customer will have ever recalled hearing about versions 5, 4, 3, 2, or 1.
Why not go to year numbers as versions, such as "FooApp 2008"? Only problem with that is it looks outdated if you don't have a new version every year or two, but that could probably be fixed with little maintenance releases every year.
With a version number as high as 5 or 6, I at least would expect to have some history behind it, and if I saw that there was none, I would remove it from my list of possibles. A company that will lie about its experience will likely also lie about capabilities, and will be generally untrustworthy. I might consider commercial software at v2.0, or v2.01, if I couldn't find a v1.0. That said, if there is a related product, that would be different. For instance, Windows NT debuted at 3.1, because 16-bit Windows, which apart from its bitness was very similar, was then at 3.1. That I can accept. Grudgingly. (WinWord jumping from 2.0 to 6.0 because Word for DOS was already at 6.0? Nope. That's just stupid.) So if you are selling Widget 5.0 now, and you are bringing out SuperWidget, basically the same thing but significantly different under the hood where ye average user can't see it, SuperWidget could debut at 5.0 with only minor grumbling.
I concur with leaving in the About box, and nowhere else. The only people concerned with looking for a version number would be those who need to know if this is an upgrade from their current version.
Where I work we will NOT buy anything that an x.0.
No matter what the value of the 'x'.
That's with an annual software budget of ~$65m.
The name of a product is a marketing decision, period. The version numbers that make sense to you as developer of the product, at best, mean nothing to the buyers of the product. At worst, well, your own example about "1.0" is perfect.
You need to have some internal scheme for keeping track of builds and versions of your product for release management and support issues, but there's no sense in having engineers decide whether a given release is 2.5 or 3.0. Let marketing pick the name that's most meaningful to buyers.
Are you adequate?
Do you work for Microsoft? Are you talking about Win 7? You must be talking about Win 7.
It does matter. Version numbers at often remembered, along with the software itself. Some people grow certain affection for a certain Version of a piece of software and want no others to come before it. And there is the opposite effect, where a certain version of a piece of software stands out as a buggy/bloated/what-have-you piece of shit...
I does sound kind of crazy, but then again, I have always been told not to start a checkbook at check #1 for similar reasons.
are the two important indicators of the level of acceptance of a software product. I think they override the version number.
Tools with an anemic user forum is a real turn off.
A quick search in google will show that a product doesn't have earlier versions. Google will reveal the size of the user base.
There are good commercial products out there with poor knowledge base and small user base, but how many of them make it to release 6?
Regards.
e.g. Inkscape, which is currently 0.46! (stable version).
It's pretty arbitrary when to go to 1.0, 2.0, etc., I would say.
...the future crusty old bastards are already drinking the Kool-Aid.
Except now their service packs are like version numbers.
Our genius marketing people decided we had to match the current Oracle version (back in 1992).
It's been 16 years, I saw this first hand and it still surprises me.
Obviously your product management people think little of the intelligence of your customer base, let alone the sanity of their developers.
All it does is tell if you have what is current. and since release schedules are different for everyone, it doesn't natively even tell you how old your software is.
Version numbers are so arbitrary that its about meaningless.
---- Booth was a patriot ----
You should really consult The World's Smartest Garbageman.
Your company isn't the only one. Check out how Red Hat went from Red Hat Linux 9 to Red Hat Enterprise Linux 2.1. A friend of mine who used to work for them told me they had a similar meeting with marketing, and marketing thought that not only would 1.0 look too immature, but that 2.0 would have too immature of a _minor_ version number. Hence it came to be that the first version of RHEL was RHEL 2.1
Not because I think you are wrong, but because sales folk typically have a different ethical barometer. You can call it what ever number the sales guy wants, but when someone does a bit of reserch online they are going to see that there is no history. I know for me personally if I didn't see any history on a product, I'll rarely buy it, and if it was version 6.3 and it didn't have any reviews/history I would think it was fishy, and definitely not buy it. Then again, there are plenty of people out there that never do reserch, so you may fool some of them. Good luck with fighting the good fight.... you're going need it against sales guys. John
I also worked in a large corporation. From the inception of a project up to the final release PM&M changed the name and version of the product suite more than 5 times (more common than you think as a matter of fact). Personally, I could not care less about the name and version (although I was pretending the contrary in from of them just for fun). However, as a developer I did care about renaming and updating the information in the source code (including the name of, for example, the preferences files). The first time, I changed the name, version and legal information manually. The second time, I refactored the code to put all this volatile information at a same and unique place. From then on, I was laughing each time the sales & marketing people were wondering if changing something would delay the release. My 2 cents: do not care about the "perception is reality" factor, just make your life simple when you have to follow the BS coming from the top...
P.S. The most funny thing was that the internal code name of the product was entirely free for the engineering, so we were putting the most crazy splash screens we could think of, a different one at each milestone build. Each time a newbie PM&M was making waves about it not knowing that the name was for internal purpose only :-)
I'm going to assume you're an Engineer. (Since you're a Slashdotter and refer to "the Product Managers".)
I think it's swell that you're all involved with your project and everything. That said, do you like it when management and/or marketing types get all in your shit about how you do your job?
Honestly, those cheese-eating motherfuckers probably really do have a better idea than you do about how to sell this stuff. Let them. You'll all feel better if you do!
-Peter
A high version number on a product I haven't even heard of screams fringe/unpopular. If I were concerned about the 1.0 effect I wouldn't print it large with the branding - perhaps only in tiny print on the back somewhere, or even not at all.
For me, the version of the software makes a difference. The very first released version I'm going to be wary of, it's likely to need some shaking-out given the industry's track record. Similarly when a package undergoes a major internal re-write I'm wary of the first release of the new codebase for the same reason. But the version number doesn't play into that at all. Call it 1.0 or 6.73, it's still the first released version and I'll still be wary until I see some real-world evidence of whether it's good or flaky.
Of course, version numbering does affect my decision in another way. If a company's straight-forward in their versioning, keeping minor revisions containing only bug-fixes and minor enhancements, incrementing the major version number when they make major internal changes that might affect stability, major API changes and the like, then I tend to trust their releases because they're giving me a clear indication what I can expect. OTOH, if they obfuscate the version numbering to try and deceive me into thinking the release is something it isn't, I immediately start to distrust everything about their software. If they're deceptive in one place, they'll be deceptive in others and I've got enough headaches to deal with already thankyouverymuch.
I think it depends who will be buying the software. I don't care what the version number is as long as there is an easy way to know what version you have. There are quite a few people though that will buy from company A instead of company B, simply because company A is at version 5.0 and company B is only at version 2.1.
Go by the year. Tell them about grassroots activism, show them examples of companies being publicly shamed by bloggers picking up tips like "software is actually 1.0 but advertised as version 6", and then tell these guys, "look, we can both have our cake and eat it too if we just call it $SOFTWAREPCKG 2009" or similar.
:-)
Now that everything is The Internet This or The Internet That, you just go out, grab some anecdote from somebody's website, and create a "crucial lesson you musn't forget" out of it. This is the answer to many a dumb question by sales guys, clients, etc.
Myself, I key in on whether or not it's "X.0" version software FAR more than I key in on that first number. 8.0, 12.0, 1.0, etc. I treat the same. However 8.1.39, 1.0.10, etc suggest some version control in action and I'm much more likely to give it a shot.
...I do have to question, why bother with a version number on the first release at all? Just call it "Brand New Product(tm)!" instead of "Brand New Product(tm) v8.9!" When the software has been around for several years and actually gets up to a higher version, then tack it on for marketing [ae]ffect. Not to mention that if I happen to follow your company's software and see a new product already in high numbered versions, I'll scoff and steer clear.
You missed a perfect opportunity for "Post 1.0!!!".
Another example of idiocy was when MAME was at version 0.99. People were demanding them to release version 1.0, because of various reasons (stability, "official" status, finished product), none of which made an iota of sense. So they went with 0.100.
Moral of the story: if version numbers matter, you're an idiot.
Wikipedia is your friend.
Interesting coincidence, yesterday I was reading that Adobe Premiere Elements 7, released this month, is the successor to Premiere Elements 4. It seems Adobe wanted the version number to be the same as Photoshop Elements so that it wouldn't be deemed inferior, also because they're trying harder to get people to buy the two softwares in one purchase.
Personally I think it's pretty ridiculous. Integral version numbers are supposed to be indicative of development milestones, not to rate the product. However, the higher a version number, the higher the chance to be a well-established software. I think this is what they're getting at. They're basically lying on the age of the product to get more respect, like an underage boy with a false ID card hoping to get in a strip club.
That's cheating and should be dealt with accordingly: "Adobe, go to your room! No more Elements for 3 years!"
1982 - First Blood
1985 - Rambo: First Blood II (ok, that seems correct)
1988 - Rambo III (what happened to Rambo II)
2008 - Rambo (alright, now you're just messing with us!)
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
It doesn't matter what the idiots in marketing tell people, "Version 1" of your software is the first version you release. Whether it's being called "Version 6" or "Version 1", people expect the first version to be buggy.
Honestly, though, I don't think I'd buy software from a company that starts counting at 6. No technical person would decide to start counting at 6, and that gives a pretty good idea of who's running things. Not only that, but starting at 6 to trick customers is a bit dishonest, and gives an even better idea of the type of people in charge. Even if it's not outright lying, it shows a pretty low opinion of the customers to think they'll be too stupid to see what you're doing.
Even if it does fool some people, it's still going to backfire in the end because the first version will still be buggy. Being at version 1 and full of bugs is expected and understandable. Being at version 6 and full of bugs just makes you look incompetent.
Maybe not
I find that version numbers only matter for SysAdmins that deal with network architecture, specifically with builds of various LAMP/WIMP modules. These slightly different packages have their own nuances with security and reliability and most Admins find it a PITA to deal with upgrades of non critical issues.
The version naming schema for your company seems to be marketspeak more than geekspeak so disregard the above paragraph. Your manager believes the version number is akin to the size of his cock and the larger the better.
Sun got to version 2.6 of Solaris then just dumped the 2 and the next one was v7. Go figure.
"Would the community feel comfortable buying version '6.3' software (and paying tens of thousands of dollars for it) knowing that it was the first release of the product?"
I would have the impression that the vendor was trying to deceive me, and wonder what else the vendor might be lying about.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
Any company capable of releasing a solid piece of software at the first version and having the balls to stand by its engineering and call it 1.0 would get a lot of respect and goodwill from me.
Here is the first question from a customer they will get. Hey what is the difference between this a version 5 and 6? When the answer is there was no version 5 the customer will automatically realize they are being used as a patsy. Next vendor please!
Just do the same thing everyone else does and start off refering to your product versions with years untill you hit 5 or 6. Then use real version numbers internally to keep your shit togather. Since I use continous integration with build scripts, automated testing etc, I start brand new products at 1.0.0.0 Then move up on each build untill it's ready for a release. Then let the marketing guys name it.
As some have already said, don't be too uptight about the marketing version or name. Keep your own internal number that you might use for branches or builds, but feel no obligation to have the two match.
It can be nice when things match, but don't worry if it doesn't.
If you want to avoid having numbers in your marketing name over time as new stuff gets added, use stepping adjectives -- like SuperFunApp Standard to SuperFunApp Plus to SuperFunAll Elite to SuperFunApp Professional.
If you want to use numbers, and your marketing folks want to start at 5.0 or something, fine. I'd recommend settling on a numbering scheme that is going to make sense going forward. Ask yourselves "What milestone would it take to move us from 5.0 to 6.0, and is that a milestone we'll cross?" Sometimes a product's really only going to come out with a set of basic features and you'll be doing bugfixes only from that point out -- maybe you don't need the "point" release.
As some have already said, you can use the year of release as your version number -- it doesn't say anything about what's in it, how polished it is, or what's next -- it's just the year.
In my current shop we have a 4-part version number: Major.Minor.SP.HF. Major is a release of the products as a suite, minor is the addition of significant new feature functionality in the suite, SP is aggregation of hotfixes and HF is Hotfix (or build number). Where we've gotten into trouble in the past is when marketing folks started dictating the internal version number. It was an epic fail and led to great confusion.
Hope it helps
.. pa-ra-bo-la, pa-ra-bo-la, 2 pi R, 2 pi R, where's your latus rectum, where's your latus rectum, 2 pi R
Think how happy they'll be when you say that software is version 1147.
Where I work (a small-ish ISV), we still try to have meaningful version numbering.
We use either major.minor.patch.build or major.minor.build depending on nebulous historical reasons.
We only increment the major if there are significant end-user noticeable changes, e.g. re-done the entire GUI. The minor gets incremented when significant improvements are made, e.g. bolting on more features. The patch gets incremented when a collection of bug fixes and/or small improvements are made. The build is perhaps not used in the strict meaning of the word, it gets incremented for every build that has the potential of getting outside the development room (e.g. for internal testing).
This means that for e.g. a planned "3.1.0" release the numbering stays at 3.1.0.0 until the first "alpha", and depending on the number of "alpha", "beta" and "rc" test rounds needed might go up to 3.1.0.15 before the "final" release.
while true; do eject; eject -t; done
One for the engineers, which makes sense (something
like the linux kernel numbering system) and one for
the marketers, which is purely a label.
Before each release, you ask the marketers what "version"
this new issue should be, and you track the mapping
in your source control system.
Don't worry about utterly irrelevant trivia. You'll just
get heartburn...
Is the major version number greater than or equal to all previous versions?
Is the minor version number greater than all previous version with the same major version number?
AS long as the answer to both of those is yes, and it isn't going to overflow on any plausible platform, give it whatever number you like. It's an arbitrary number.
A new product based on an existing product line that is well established and at version 5 and using more than half of the original code base. The new product is just retargeted for a slightly different market. Should the new product be 1.0 or 6.0?
But not because of the version numbers themselves, but because any marketing "genius" with enough clout to push this through probably also did the usability studies thus it will be a royal pain in the arse.
A 1.0 product would mean it was made by engineers, not marketing people, thus might be useful so I would at least try it if they had a full featured demo (and I mean a real one not one of those stupid flash things)
Heavily bias opinion as an IT Engineer? Yeah... but you asked :)
Car manufacturers don't put version numbers of their car as part of their marketing. I suspect that people don't buy first releases of new platforms, so there isn't the same incentive to get the X.0 version of the car until the manufacturer takes a look at the warranty work and fixes the bugs in the design.
However, most enthusiasts do know the internal numbering system. For instance, the Audi A4 was released in the B5, B6, B7 and B8 platform. If this was software, it would have been Audi A4 1.0, Audi A4 2003 Server, Audi A4 XP and Audi A4 7.
I find it more so the idea that a software piece that I have just found out about at a version of 8.0 is a hoax. If it just came out and I am just now noticing it and it has a high version to it, then i am suspicious. My stigma has to do with the fact that a company is not willing to be honest. By putting 8.0 they will prob never support it again making people think that it is the best it can get. They also say that we have done the testing and it is good, and when it turns out to have more bugs than an any pile in the summer, the company loses credibility. It is a dumb idea to put higher version numbers just so people don't think it is new. IT IS NEW SOFTWARE, start it at 1.0 and let me know that if there are bugs they will be worked out. I buy 1.0 software all the time as long as it is promoed properly and by that I mean that the company gives me all the features and not some showy movie that doesn't explain everything. I want to know the hard specs of the software, even down to what coding language you are using (this is important imo).
Have the product version number as what ever marketing want.
Have the build version number as what ever engineering want.
Use your CM system so your internal revisions use your numbering scheme with the marketing scheme being applied as a tag to the relevant files...
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
Being a hip grandmother and trying to keep up with technology can be difficult. I am considered educated by some but find myself acutely aware of the outdated programs that grace my bookcase.Having to carry a cellphone for an entire working career can be a real pain.The first one I owned had a battery pack the size of a small suitcase.(NO kidding).What I am politely trying to say is NO,I would not buy anything that said 1.0.Only because I would think the store had it for a while and was trying to get rid of it on grandmothers like myself.Magnet12
Release it as beta, seems to be working for Google so far...
... I run in the other direction, if I can. Any choice other than "1.0" (or similar) for an initial release only indicates to me that the vendor has something to hide.
Version *.0 never works. *.1 will work.
Therefore, always release 2.1 instead of 2.0.
2.1 will work.
2.0 won't.
Everything will be fixed in SnowLeopard.
"They told me it was impossible. I replied with maniacal laughter." http://www.mydailyrant.com/
..... who were in the clinical tests for Preparation A through G?
Please let us know what company it is that things we're all such idiots that we don't pay attention to these things, and believe we simply must have missed the prior versions, so we can avoid them. We will even if you don't tell us.
If the game isn't good enough to release as v.1, it's not good enough to release. Their tactic will trick some people into buying it, they'll figure this out, and never buy another.
The software version/revision number means nothing if you put a number 1 in the title instead. It implies sequels. People like games that will be continued-on-next-disk. Try telling this nice thing to the suits. If that doesn't work, tell them the bad ones. Tell them either way they're stupid, but can either act like it or not.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
A product family is used as a generic name for the whole family and if you don't have version numbers then you have hell.
Customer: I'm using WizzoProg and getting this problem.
Tech support: Which version of WizzoProg are you using?
Customer: WizzoProg. I couldn't find a version.
Tech support: Ok that must be the original Wizzoprog.
Five minutes of confusion....
Customer: Oh, you remember you asked for the version, I can see know it is V3.2.
Engineering is the art of compromise.
These days any number in a product title is just a brand, and is meaningful only insofar as it differentiates "now" from "has-been" in the eyes of the wearer. There will likely not be a Windows 8; they'll probably switch back to names or something else entirely.
Any useful diagnostic purposes that version numbers might have served back in the day are today served by build numbers or Subversion revision numbers.
/. -- the Free Republic of technology.
This isn't really quite as dilberty as the poster indicates. This is a symptom of a more general problem, which is that non-OSS software almost always sucks, because the economics dictate that it has to suck.
First of all, let me throw one big [citation needed] on there. Your whole argument starts with the fact closed source sucks because it's closed source, and open source doesn't because it isn't. You hint at something about economics, but that looks like hand waving to me. With an opening argument like this, the rest of your post is surely going to be just as fun...
If it was OSS, users could install it on their machines, try it out for a while, and decide whether it was any good or not.
Closed software does not automatically mean you cannot try before buying. Quite a few closed source applications have free trials or even free versions. And there are surely Open Source products that are not free. For example non-commercial clauses. I think you are making the mistake of confusing Open Source with free. Which actually makes you a fairly uneducated OSS Zealot to boot.
(Note that this still works fine for commercial OSS. E.g., people can try Ubuntu before deciding whether to deploy it widely in their organization and then pay Canonical for support.)
Again, you are mixing up OSS with free. One could imagine Windows having a free trial. You should think about if yer really talking about OSS or cost.
If it's not OSS, you don't typically have any way of knowing whether it's good or not. Sure, you could read reviews, talk to friends, etc. But that's sort of like deciding to buy a car without having a chance to test-drive it, just based on your buddy saying he has one and he likes it.
So wait a minute. More hand waving here. How exactly do you know if software is good or not by the virtue of it being OSS? There's the tired of argument of 'Well you can read the source code!' Yeah right. How did you decide FireFox was good? Did you read all the source code? And even if you are crazy enough to do that, who else is? No, you probably heard about it word of mouth, just like you would with closed source software. I think again what you meant is, 'If it's FREE you can try it without paying for it.' However, see above.
The worst piece of non-OSS software I ever owned was Adobe PageMaker 6.5, but the only way I found out how bad it was was by writing a book using it, and finding out after I'd gotten pretty far into the project that PageMaker was gradually starting to corrupt my files, and was also crashing often enough to cause me real problems. It would crash one day, and I'd lose my file. So then I'd open the file again to page 93, which I'd been working on, and it would crash again because page 93 was corrupted. So then I'd get the file back off of backup. But then I'd click to page 87, and it would crash again. So the backup was no use either, because it was corrupted on page 87. In this example, there's absolutely no way I could have tested the software sufficiently before buying it to find out that I was going to have these horrendous problems.
So how long should a free trial be? I think what you want, again.. is free software. You -never- want to pay for it. Maybe you'll make a donation later after you've used it a few years. Maybe. And as for the long sob story about losing your data, if it's closed or open source, could have the same bugs, and still lose your book. I don't see how this is, again, any sort of argument for OSS.
Because users usually can't evaluate the quality of non-OSS software very effectively, there is absolutely no incentive for non-OSS software houses to work on quality.
Wow. I'll have to remember that. As long as I keep my code closed, I can write crap and people will buy it. Oh
Your PM's idea demonstrates a contempt for the customers' intelligence. Does he/she really think your customers won't notice this ploy? And when they do, imagine how much confidence that will inspire in your products.
Tell your PM to back up his assertion with data. What he's claiming is hardly better than an urban myth, and is probably wrong.
For three years Google News was in beta and it didn't seem to dent its popularity.
That being said, I usually look for a version that is close to X.0 or X.1 , the reason being you often get free upgrades within the version number, so if I get a low number, I know I will get lots of free upgrades.
If I get 1.8, I know they will shortly jump to 2.0, making any upgrades costly.
If the pattern goes 9am, 10am, 11am, why isn't noon 12am?
Just don't advertise the version number! By indicating 1.0 on the box, you're almost stating that you anticipate bug fixes.
The movie Jaws wasn't marketed as Jaws I.
I swear to God...I swear to God! That is NOT how you treat your human!
This is not a new thing. In the early 1980s, not only did George Tate opt for dBASE II instead of dBASE I, because he thought it would be considered to be more stable, but he also invented a fictional "Ashton" to make the company sound cooler "Ashton-Tate".
If it will make you happy and make your boss happy, why not declare whatever development version you have RIGHT NOW to be 1.0 and start incrementing from there? Then you can be just like the games which ship with patch 1.02.
version numbers usually mean new features. Minor ones bug fixes. That may not be universally true, but it's my perception.
I think I'd feel happier buying a version X.15 than version X.0 regardless of whether X was 1,2 3 or 6..
Nullius in verba
"I had assumed that the version number for this product would be 1.0 (***at most****)." (* emphasis mine*) So, your view is that the professional software that your company wants to sell should have something like "v0.2.1" in its name? And you would seriously expect people to buy this? Sorry, I just had to bring this up, maybe v6 is an exaggeration, but to say "I was expecting this to be 1.0 at most" is kind of not so reassuring either...
It is really going to depend on the track record of your company (and, eventually of your new product itself.)
For some companies, people won't deploy ANY .0 product until there's a .1 or SP1 release. For others, they want the latest-greatest stuff regardless of the release number.
Since you're in the position of having a new product, now is the time to set the track record for it and make your 1.0 release work as perfectly as possible. If it is slow/buggy/crashy/bad, then being versioned 6.2 isn't going to help it at all.
I was going to ask the O.P. the following questions. How does a salesperson respond when a prospective client asks:
1) "What are the new features in this version as compared to the previous version?"
2) Or, "We want to compare the new release to the previous release. How can we get a copy of the previous release?"
3) Or, "We'd like to contact current users of the package. Can your company provide a list of current customers whom we can contact?"
4) Or, "Please provide a list of all of the service packs and patches released for the previous version, the time from when the problem was identified to when the update was made available and whether the update resolved the issue."
I could go on but I think everyone sees a pattern here. Making the first release of a product version 5.0 or some such nonsense works as well as most lies. The only way to maintain the lie is to tell more lies which then beget a need for still more lies. Eventually, it all unravels although current management may be under the impression that they can take the money and run before they're found out.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
If it starts with 6.0 and I happen to know it is a new product I begin to doubt anything else you claim about the product. I expect those I do business with to display a high degree of integrity and this displays the opposite. Customers do not like to be lied to.
... and no one will care. The truth is the only way you'd care about version #'s, is if your software isn't that good or desirable to begin with. Add value and design something people want to buy and people will buy it.
any manager these days know to ask how many they are.
So you could be on version '10' but only released two versions.
Version number should ONLY be compared to a specific product, not as a comparison to every other product.
The Kruger Dunning explains most post on
As other posters pointed out:
1) Your Product Managers are trying to turn the version number into a marketing point.
2) This is very deceitful because your Product Managers are trying to obfuscate the maturity level of the product. This is equivalent to printing "First released in 2001!" on the box.
So how you react depends on your ethics and how much you care about the company. If you care about ethics you should fight this because it makes YOU look like a liar. If you care about the company you should fight this because it's stupid and will harm the company's reputation. If you don't care about either of these things, let them call it whatever they want.
One suggestion would be to use an less dishonest version indicator in the product. Call it "x 2008" or "x Professional Edition". Or simply "x" and leave a version number off the product. This is common with 1.0 products.
To me the question is who is driving?
Marketing? Yea, I can see not using 1.0 but in that case it only becomes part of the name and is not reflective of the actual software version, like how no matter how you classify windows there is still a 5.x.xxxx version number in the About window.
Development? It only makes sense to start at 1.0.
Personally, I agree with the other commenters. Don't attach a version number to the name at all. If your QA dept has done its job properly, then there shouldn't be enough bugs to illicit a "man v1.0 was crap," response anyway. Sometimes making your potential clients a part of beta testing is a good idea...
Out of curiosity, was that PageMaker 6.5, 6.5.1 or 6.5.2?
(Got a lot of use out of PageMaker 6.5.2 in high school yearbook. I don't remember too many crashes(maybe it did, it's just been 6.5 years since I got out of high school)(and we did crash the system at the publisher. 600 MB graphic file(linked) in one file that opened fine (lots of waiting) on a 32MB box. Caused theirs to crash) , but the worst it would have done would have been a single spread (2 pages) (so a corrupting crash wouldn't have been as bad for us. You had lots more pages so I could see it being much worse) )
I think that the industry in general would be very wise very quickly to a company trying to release a 1.0 version of the software and calling it 5.0, 6.0 or anything else. I think its one of the primary reasons that Microsoft (until recently) has quit "numbering" their releases. Windows XP, Windows NT, Windows Vista, Office 2007 (even though internally it's called Office 12 still - look at your install directory names!). There is a huge disadvantage to any software in the marketplace that would want to be called 1.0. I think it adds skepticism of the newness of a product. I think I would advise your company to completely skip the 1.0, 5.0, 6.0 and just name the product appropriately...maybe Product 2008 or something like that.....
Start at Version 6.3 and work down, gradually removing features and making the product less stable. When it gets to Internal Release 0.01 Alpha, leave the company and go back to college, starting in the last year. When you finish college, go back to school. When you finish primary school (by running backwards out of the gate in to the arms of your mother), spend five years playing with Lego, then Duplo, and finally mud, before crawling feet first, screaming, in to a dark hole and dying.
If only everything was so simple.
His product is clearly a FooGenerator!
There are many different products that base their name on the amount of development time, rather than the release version. This is why we have:
Formula 409
WD 40
Heinz 57
Nylon 66
Basing the release version on the number of internal revisions has been appropriate for a long time.
Certainly not if I know it's the first release! It would be obvious you're jerking me around. Or was that a rhetorical question?
Just call it X, or if you're planning on sticking around long enough for a second release, call it X 08x10 like Ubuntu. Or if you really want to confuse people call it "X, the Joey release" like Apple does.
In other words, your product release name has nothing whatsoever to do with your internal version number.
Oh wait, everyone else who answered said the same thing. Never mind.
(Just don't call it "X11" -- that's taken.)
I maintain Finnix, a system maintenance livecd. The first release was 0.03. The next release was 86.0. Why?
1) Why not?
2) See 1.
3) It had been 5 years between releases.
Finnix is currently at 92.0, and I've got to make a decision about version numbering soon. The reason is simple: "There Will Be No Finnix 95", for obvious reasons. I may just jump from 94 to 100.
I've noticed that, when Finnix is on a X.0 release, people tend to transpose it incorrectly a lot more often, saying "Finnix 0.92" etc. I think many people just cannot comprehend a version number greater than 10 or so.
As the developer on the project, you have the best job of anyone, certainly better than marketing, sales, etc. No matter what the product name or version #, those folks can make it succeed or fail with many factors completely unrelated to the software or its quality. Let the pointy hairs worry about that stuff (or become an entrepreneur and control the whole sh-bang). Relish the fact that you get to build a cool new product!!!
There does seem to be some thing to the version number. 1.0 is new, I'll wait for 1.1. 2.0 fixed the rest of the bugs and introduced some new ones. 3.0 is pretty good. 4.0 really shines. 5.0 introduces some stuff I don't need. 6.0 adds email capability, 7.0 adds PDF export, 8.0 completely redid the UI so I'm annoyed as long time user. That seems to hold true for some of fairly common apps out there.
I think however there is a difference if the app is commercial or open source. I assume an open source app at 1.0 is a 3.0 commercial app.
Personally I think your company is being silly. If I see a brand new app at version 6 that I've never heard of and can't find any reviews on Google about past apps I'm going to wonder what's up.
If you want to be a little more honest, get to version 1 *now*, release it internally only, then release version 2 to the public. That way you at least have a story to tell that is legitimate.
The marketing and external folks can call it "Super software 2009". The average folks have no idea how long the software has been around, but it makes them feel good that it's up to date.
Internally, for the sake of builds and quality assurance, give it a good ol' version number that most folks would never pay attention to.
Seriously, once in a blue moon Microsoft has a good idea, and that was one of their best IMHO. Of course, that idea was around before them, but it's still a good way to go about parsing the marketing folks out of product versioning.
Personally I wouldn't be against buying v1.0 software, it is always patchable so I don't worry about bugs. But more or less the first release of software shouldn't include a version number at all in my opinion. This gives the impression, I think, that the software was made for its purpose and was made with forethought to never need v2.0 in the first place, even though its not true, it looks more attractive.
If they have a problem with 1.0 then just dont have a number or use something else like "VinTopia 09" for the year of release, or "Vintopia Pro"
Lying about the version number is just bad, because well - if you lied about the number printed on the box, what the f*ck must be inside?
* Game Over * High Score: 264,846,927 -- Your Score: 14
Yes is the short answer. Most customers that i have dealt with (and I have dealt with 1000s of enterprise customers) and have personally been responsible for rolling out new releases of multiple products. Each product creates its own track record of what is considered a stable release. In our case our customers would always wait for the first service pack for any major release before they'd upgrade.
Version 1.0 was definitely out for us. No customer would have picked it up for their production environment. So the bottom line is that there is nothing Dilbertian about version numbers. Customers want a stable release and version numbers should be based on their perception of what constitutes a stable release.
Slashdotters and engineers may not like it but that is the way it is. If you have trained your customers historically through consistent communciations that release 1.0 is stable and is preceded by long betas (like google) then 1.0 is fine.
I don't buy version 6 of anything after getting burned with PC-File years ago....
lol version 6 was entirely different product than 5.0 that ran at half the speed of the old one. It was so bad the versions sequence was 5.0, 6.0, 7.0, 5.5 !!
Seriously everyone seems quite capable now of screwing up whatever version they are building :(
The .3 is a nice touch tho....at least until people find out it is fake. Then when it is buggy or lame people will probably consider everything from that maker as sucky ;)
It doesn't matter what you call it.
I prefer versions by date with a letter indicating which build that day. Bob_20081015a would be the first today. At least that way people know when you released that version...
however since your company is full of scammers it's best to figure out how to get your share of the rewards. Just kidding... name it what ever they want... they pay your house mortgage don't they?
If it's version 6.0 and it's buggy, you've just shot yourself in the foot and no one will want to buy future releases of your product. If it's v1.0, then there's more leeway given. Version hopping is for those who have learned enough to be dangerous. Those who don't know are blissfully unaware of the version of their product. Those who do have the knowledge don't upgrade just because there's a new version. It's those in the middle that equate newer with better - and they quickly learn their lesson as their wallet is emptied. This is a prime example of a business that's more interested in immediate profits than it is in retaining a loyal customer base. I'd suggest looking for employment elsewhere.
A good mantra for new software releases.
I hate being bipolar; it's awesome!
What would YOU do when you tried to research FooBar v6.0 ... and could not find anything at all about v5 ... v4 ... v3 ... v2 ... v1 ?
My first thought would not be that Marketing had fucked with the version numbers. It would be that that company's past product have sucked so badly that NO ONE would use them.
If I cannot find a SINGLE user who is happy with v5 what does that tell me about the likelihood that v6 will be decent?
And when I find out that v6 is really v1 ... but Marketing wants to fuck with the numbering to FOOL people into buying it ... no way. I'll go with a competitor's product. That's just too many warning signs for me.
Sorry if I haven't been enough of a purist about this. I promise I won't inflate the version number again (unless everyone else does again ;)
http://www.slackware.com/faq/do_faq.php?faq=general#0
Everyone KNOWS that 6.3 is a standard for filament transformers. After that, you get 12.6V
They always knew how many previous versions were available, and previous versions weren't always named by versions numbers: win 95, win 98, xp, vista, windows 7... etc.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
I assume that this software costs more than $1.00, so do you think you will fool anyone ? If your first version is 6.0, people will look for reviews of 5.0, not find them, and draw their own conclusion.
Do it the Google way - beta forever.
Much depends on the customer. Most are quite stupid. But then you say the price the over $10K. Then I might expect the customer will at least have asked around. They will quickly find out that even with the version at 6.3 there ARE NO OTHER CUSTOMERS. They will then think "something is wrong" suspect fraud and bail.
If I knew it was a 1.0 release then that would explain the lack of existing customers but a 6.0 with no existing user base? I'd be thinking "scam".
But on the other hand if the software were to be sold retail in a box as an "impulse buy" for $29.95 thaen you could expect you customers would fall for the scam and maybe never even find out. But with a $20K price they will at least try Google to find reviews and the like and when they come up missing... not good you've just lost the trust of a potential customer.
Don't lie- it looks bad. Marketing is a big thing. Do it correclty and the (internal) version number does not mater. Do it badly and the PUBLIC number will KILL your product and the company due to BAD press or word of mouth.
Don't use a Public version number. Use something publicly that means NOTHING to the version - Like the Year. "Ultimate edition" or some kind of code like some version of Linux that use code names - even Windows used code names Like VISTA XP NT ME 98SE etc...
If people find out that your markeing a verion 4 or so - My question is .... Can I ask someone with version 3.X...... See a older review somewhere etc... When I found out that there is no prior version - the heck - no way man. You like are like deceiving me - don't want it now.
Yes sending out verion 1.0 is not really good (marketing wise). Find a few alpha/beta people - give them the 1.0 version. When you debug it - then change the internal number to 1.1 . When you have that out for say 6 months to a year. Fancy things up or add a feature or two - Call it Vesion 2.0!
I have purchased a few first version of commecial s/w - what I looked for if they are actively updating/fixing bugs (like a small update every week or so) and if they have a forum. If I look at a company and thee is only 12 posting in a forum and there on version 4 or whatever - WTF.... But if it is version 1 or 2 then it is a littel bit more understandable....
I have never, ever had a good experience of a version x.0 from IBM, or many other vendors in fact. I'd rather pluck out my own eyes than risk another one of them.
Quite a lot of vendors deliberately start at x.1 just to avoid this.
Marketing is about dealing with perception and addressing it. If the marketplace has a perception that x.0 versions are buggy and nasty, the marketers need to deal with it.
At least it shows that your marketing team are tied into the beliefs and opinions of the marketplace.
--- Band: Joey Ultra
I ignore the version number. v5 may be a total re-write and be as buggy as v1. I am more interested in how frequently and when the last update is. Too many small updates may indicate lots of unresolved problems in the "release", a bad indicator. Too few updates may indicate lack of support for the product. It depends on what those updates are though.
I think there are basically two buyers - those that research and those that don't. Version numbers are the "research" for those that don't.
You are right there is a certain stigma to using version 1.0 software, but you get a much worse response if a customer realizes you just started version 1.0 at a higher number.
.
My experience with a small/medium software company has been to basically make the versions mean something. We use a reasonably standard formula for version control [major].[minor].[build].[revision]
Basic meanings given to new programmers: Major: drastic, often incompatible, changes between code versions
Minor: published bugfix collections and minor user-driven feature additions
Build: single bugfixes and basically anytime you recompile something you send to customers
Revision: mostly unused, but handy when performing hotpatches for clients until a full bugfix is released
The other really important piece to do when using version control numbers is to keep records of changes and who was in charge of making them. This makes life much easier from a support standpoint because when something breaks, it's nice to narrow the source down to a few people who touched it last or who wrote it to begin with.
If the package costs more than $20 I'm going to want to talk to someone who's used the product.
And one of the questions that I'll be asking is about their experience with upgrades. After all, version 5 means that they've gone through what I would consider to be FOUR major upgrades. What kind of support do they have for that? How painful was it? What hoops did you have to jump through. What "artifacts" are still lingering around from the previous upgrades?
Thus, who would be fooled by a miraculous appearance of a 6.0? In other words, this is a version of "these go eleven" "Our software starts at '6!'"
sigs are for losers (except to point out that sigs are for losers)
I hate that year equals version scheme. When we were rolling out Office 2007, my helpdesk got several requests for "Windows 2007". All you can do is laugh about it. However back when we were rolling out Windows XP and Office XP at roughly the same time that kind of confusion really had an impact.
I am pro OSS but your argument doesn't make sense... how would having access to the source have changed your experience? Do you read through all the source of apps you are thinking of installing then mentally re-create the experience and all possible permutations before actually running them? If so, you have a pretty awesome brain that I would like to try running Crysis on (I know, I know, but I can't help it!)
Version 6.66
In GOD we trust, all others we monitor.
These are links for the Libby Hoeller videos:
Part 1
Part 2
Part 3
Part 4
Complete (?)
Just about any software, or any product for that matter, gets its share of reviews in the press, blogs, forums, whatever. With a little bit of searching, a buyer is going to find out all the good and bad about the current version, regardless of its version number.
I totally agree with the parents post.
Another option for the original poster would be to name their product after the year, as in
FooBar 2009, or even more vague as in just plain FooBar
..........FULL STOP.
There's actually 2 versions of a product. One is the marketing version, this can be anything FooBar 2008, FooBar 8.04 (representing months) FooBar 2008 sp1 patch2 etc.
The other version number is really required for support. This needs to be able to specifically identify the build/patches applied to be able to provide the customer with help when they run into trouble. It can even be a build number. It's not sprayed all over the product as that is what the marketing version number is for. But maybe there's a particular screen or command line utility that provides this information.
The beauty is that if you recognise both, then you don't even need to enter into the marketing debate. It's nice to be able to say, "You can call it whatever you want, we just need to know x months in advance so we can put it in all the right places before testing".
If you want a specific example of this, look at Internet Explorer. It's marketing version is Internet Explorer 5 or 6 or whatever, but if you go to Help/About you will see a version number 5.02.0123773 which is probably a build number or something.
hth
ws
So does Anonymous Coward have good karma?
Your manager is ridiculous but you gotta do what the boss thinks even if its stupid, like it usually is. Its probably worse than you think. It was probably your boss's boss who came up with it. And he or she picked it while attending some conference or meeting somewhere, or read in one of those pinhead management books. Maybe they had a big meeting in the conference room and put those sticky notes with all their clever ideas on one of those easels, and use root cause analysis to come up with the answer. Of course they probably still have it up with a big do not disturb sign on and they worked on it all weekend. six of one or half a dozen of the other. Let it go. Don't end up on anti-anxiety or depression medicine over it.
I was reading about the history of Lockheed (spelled Lougheed back then). The Lougheed brothers named there first aircraft Model G for similar reasons.
Guess what, kids: None of them are real. I know that Computer Associates spent a lot of money evaluating what version number and numbering schemes inspired the most confidence. And I worked for a company back in '94 that published 5.1 as it's first public version. Overtly deceitful - or sound marketing? Is there a difference anymore? Guess not, because I wasn't about to quit over it. And who said that you had to add '1' to the hit-counter of a web page? Or even that it had to start at zero? Why not start it at 1,147,323 and add 7 for each visitor? Question everything and trust nothing.
Having said that, I'm afraid that Upper Management will soon be engaged in a massive rebranding exercise as they find that the market shuns a certain software product from a particular company that displays "1.0 quality" when the version number reads 5.x or something. They will probably have to completely rename and rebrand the product and perhaps even see damage to the name of the company as a whole.
I'm sorry to say that that it looks as if that's the way things are going to be. You see, rebranding products is something that Management understands, and they might just be happy to look forward to an exercise that falls squarely within their core competency. I don't think that damage to the name of the company will impress them however, since that typically is a long-term thing. Longer than their likely tenure with the company in question anyway.
Having said this, it's not unlikely that you will see an urgent demand for bug-fixes (apart from the usual demand for additional features) as the product meets headwinds in the market. There is a chance that this will enhance your job security, highly desirable in an economic downturn, so don't look down your nose at it.
What you might do is start thinking about what type of defects the product is still likely to exhibit (despite your best efforts during development, testing and debugging), what additional features are most likely to be demanded, and start thinking about how to go about fixing those bugs and implementing those new features plus how much time / effort that would take. Then when the defects emerge you can impress your boss with a calm but supportive attitude, and well-thought through plans that offer him alternatives and allow him to offer sensible options to higher management.
Besides which, it's not unheard of to run a book among your co-developers with bets on what general type of errors will be found and what priority Upper Management will attach to them. Only, be sure not to let Upper Management catch on, as they will then insist on placing bets themselves and will adapt their priorities in a way that will make their own bets come true. Be warned!
Sure, if you prefer, just s/OSS/free/g throughout my whole post.
Here you're ignoring the argument of my post, which is that you can tell whether it's good becauese you can install it for free, and test it as much as you like.
And here you're responding to an argument that I didn't make at all.
Again, you're responding to things that I never actually said. I didn't say anything about a free trial for a limited time. You said that.
Again, you're responding to things that I didn't actually say. I didn't say I never wanted to pay for OSS. In fact, I specifically gave the example of paying for support for OSS. I didn't say I wanted a limited-time free trial of proprietary software. I didn't say I wanted to use shareware whose author requested donations. You said all that.
Well, for one thing, by the time I found out how buggy it was, I was locked into a proprietary file format. Also, what I usually do with OSS software is to start off by messing around with a little, then if it looks promising I use it a little more, on things that matter more to me, and then if I start to gain some confidence in it, I go ahead and hitch my wagon to it for an important project. Not so easy to do that with expensive proprietary software like PageMaker.
Except that we see lots of cases where it doesn't work that way. I gave an example where it didn't work that way: Adobe PageMaker. You gave another example where, in my opinion, it didn't work that way: Windows.
Actually you're recapping what you said and I didn't.
Nice ad hominem attack. I'm 42. But I guess it's easier to attack me personally, and to respond to things I didn't say, that to read my post and respond logically to the things I actually did say.
Find free books.
The majority of commercial software is produced as a cottage industry instead of a project - it's done in a similar fashion to individuals independently weaving baskets and the only management input being cries to weave faster.
Now contrast that with a major and popular OSS project where a lot of people are looking at a small amount of code - you only get that scrutiny in the closed software world if you have several military customers and they demand to see the code.
Of course in open software there are also plenty of failed or disorganised projects too but they tend to sink without trace instead of the commercial equivalent where you have salesfolk shoving them down your throat.
Google's a prime example. The majority of their online apps have been in 'beta' for how long now? This doesn't seem to deter people away from using them since their apps have a good rep. I think it matters more about how reviews, word of mouth, etc. speak about a product. However, in a corp environment things could be different. Purchasers looking at software may think v7 of something is way better than v1 of another. Even though v8 is infinitely times more bloated than v1. Sad, but that's the reality.
Also, look at the Linux kernel. Version 2.4 is still widely used if one isn't worried about having the latest and greatest. One would think 2.6 is way better to go with, although this is untrue. It depends on the application.
your software version in the first place?
I never bought I program that was named after it's version anyway, but thinking about the software I'm downloading I have to say that yes, version number if stated is important to me. For example if I'm looking at an open source database, where there can be found different programs having almost the same purpose I will always try first the one that has reached version 4.x over some other one which is still at 0.x or 1.x.
I realize that it's mainly psychological as there is no evidence that 4.x means better than 1.x (maybe it is even buggier the first one that they had to realise so many versions to make it work), but I think that it still has a role.
Then again you can see big software houses that rarely state the real versions of their products, probably for that reason. The fashion now is to name yuor products by the year they were released in. Some examples that come into my mind could be Windows of course, but also Ubuntu releases, Norton antivirus ecc...
Not to mention the fact that you NEVER put in the even numbered service packs.
Purchasing 1.0 software wasn't ALLOWED at more than one company I've worked at.... Asking pretty much got you laughed at.
--Toll_Free
then you've got bigger things to worry about.
(...though maybe "Version 2.0" is OK for "first public release")
No sig today...
When I think about version 6.0 or version 5.0 what I generally think is that is must be bloated. In my opinion version 3.0 is the ideal number, past there it's just kind of silly. Version 1.0 is the initial product release, it's generally full of bugs and other problems (essentially a larger scale beta). Version 2.0 cleans up 1.0 but doesn't do too much other than that. 3.0 adds the new features and doesn't break it. Versions 4, 5, and 6 tend to add more *features* that add bloat and other things that are unwanted like bugs that arise from adding too much to a design that wasn't meant for it. Versions 7 and 8 are usually better though. All in all you should start at 1.0 because it's honest, but you should get it to 2.0 as soon as possible with as many improvements as possible so you can say 'Hey, look at how much cooler this one is". If you are going to go the marketing route then either start at 3.0 or 7.0, the rest should just be avoided.
I wouldn't so much care that it's called 6.0, as much as I'd ask for users of version 5.0(and 5.1) for how quickly bugs were fixed, etc... Especially if it's enterprise software. No way I'd risk being the lightning rod for my users unless I know which way the lightning blows... A company that would have a "first version" called 6.0 would be branded as "1.0 and a bunch of liars to boot" ending in the worse of both worlds. I doubt it's a rare attitude in enterprise software buyers/influencers either...
I do not pay attention to version numbers, but certainly I do pay attention to misleading marketing, and tend to vote with my money, so a software house wants me as their customer they would certainly need a 1.0 first.
1.0? Wouldn't that be like, the 1990's version? Gosh, I can't see myself buying anything at less than a double digit version number these days. Can't wait for Fallout 10!
My own numbering system hasn't failed me yet -
Major number: Increment to the next largest prime number every time there's a total rewrite.
Minor number: The more useless, the better.
As an example, my 1.x started off at 1.04 and ended at 1.23 with separate releases anywhere from 4 days to 8 months apart. 2.x went from .0 up to .13 then jumped to .50 and .60 for no reason. 3.0 never had any other releases because it was the most evil code I'd ever written, and 5.x is every x'th day of the x'th month - meaning I'll have to rewrite everything after December 12th. :D
...is they'll say "How the heck could there be 110 of these things and I never heard about it?"
-- thinkyhead software and media
We have language inserted that says if the software isn't working the way we want, we can get a refund. Most reputable software companies are cool with that.
Geneally we've found that if a company won't back a product they've produced, then doing business with them doesn't make much sense.
Yes Francis, the world has gone crazy.
Marketing people are evil.
A 1.0 product is for the early adopters. You won't make a lot of money, but people will give you great feedback and guidance, that will make your 3.0 release a grand slam.
Step 2: x = x+1
Step 3: ???
Step 4: Profit!!!
Is risky to the company reputation if the market discovered the truth behind the version number of the software. The consumers may feel cheated.
...who regularly recommends software to a Fortune 100 company I'm smart enough not to be fooled by such a simplistic marketing gimmick. We do market viability studies that show which "true version" of the software is currently on the market as well as a 5 year roadmap of the product. More than anything I'm irritated by it more than anything, especially when the software doesn't work properly.
No, it carries no meaning whatsoever.
After all, one fool may think the software is ready for the version 1.0 label, while a more experienced manager would say no, that's a 0.8 at best.
Also, I've worked at companies that make new products using the same underlying libraries that older products use. In fairly serious production environments, often it's more important to know what the underlying version is than anything else, and therefore we would label it with the version of the libraries. This was expected by our customers, as well.
expandfairuse.org
Super Product 2008, or 2009. Keep the version (or build) numbers for internal use.
A few years ago, I worked for a network operations center at a university, and we managed the internet access of over one hundred thousand users (mostly the university interconnects and the internet gateways, not everything down to the dorm room or anything like that). We were toying with the idea of using a ticketing system to handle issues that cropped up, and I was asked to evaluate some open source software packages.
Eventually, I found Request Tracker, slapped together a demo server, and showed it to the "Director of Technology." He stroked his beard. "It's okay," he said, frowning, "but the ticket you just created has the ID number of 1."
I shrugged. "Well... yeah," I said. "It's the first ticket."
He shook his head. "That's not going to work. We need to be able to start it much higher. Otherwise everyone is going to know that the software is new."
I stared at him. "We get phone calls from about two dozen network engineers," I said. "We're on a first name basis with all of them. I think the giveaway will be that they get a ticket number at all, not that it's low."
But he was adamant. I was annoyed enough by the whole conversation that I stopped working on it, and for all I know they're still not using a formal ticketing system. (Which is probably just as well, because even if they'd started a ticketing system at id # 0, four years later they'd probably be into the low three digits.)
Seriously. Your job is - as far as I can gather from the article - to make the product. The marketing people are challenged with selling it. Let them do their job and if they think 6.0 will sell better - why bother arguing even if their decision is stupid. If the product contains bugs you will be blamed - if it does not sell the marketing and/or the sales people will be blamed. This just seems to me like a internal political infight that is just not worth it mostly because it can not be won.
e.g. qt3-3.3.8b-14. My distro's packagers does this to allow parallel install of QT 3 and 4. Just name your package something like foopackage6-1.0.0rc1. And when you upgrade to seven, it will be like foopackage7-5.0.2.
Colorless green Cthulhu waits dreaming furiously.
Internal for revision control use whatever you like but Why not release without a version number.
1) "What are the new features in this version as compared to the previous version?"
It's got hypermiling with inflation inhibitors and a new "works first time" system to avoid discombobulation.
2) Or, "We want to compare the new release to the previous release. How can we get a copy of the previous release?"
It's not available there are no copies left from production runs.
3) Or, "We'd like to contact current users of the package. Can your company provide a list of current customers whom we can contact?"
We're interested in your security .. we put our clients first and that's why we can't share private business details between clients.
4) Or, "Please provide a list of all of the service packs and patches released for the previous version, the time from when the problem was identified to when the update was made available and whether the update resolved the issue."
All complaints are dealt with by our first rate support teams ensuring everything is fixed immediately and without delay. All products have bugs of course [smile, shrug, light chuckle] but our industry beating QC process ensures ours don't impact your bottom line.
Eventually, it all unravels although current management may be under the impression that they can take the money and run before they're found out.
Of course you can pay now. Do you want to take out product defect insurance - it's only available until the end of the day and will ensure that should the worst happen you'll be covered every step.
The concept of versions is important to articulate the API implementation that you advertise to your end user, if applicable. For example:
My Product 1.0 and My Product 2.0 will probably have significant differences in the interface (both user and programmatic).
It is important to note that any goomba would be able to Google for the product in question to determine its history (or lack thereof).
Now onto importance - is it? Absolutely. Take for instance Mac OS X . Apple proudly announces that its OS is no longer a mere sequence digits but uses the roman numeral instead because of its marketability. So, yes, the version number is important. However, unless you're attempting to sell the product to a bunch of goombas, it should be fairly easy to determine that your product is lacking tested experience. Further, when all the "1.0" style bugs come out (and they will), it will further concrete the customers' notion that they made an uneducated choice to purchase your product because of the impression that it is a sixth generation product.
Your management should stand by the quality of the product and be able to advertise it, even if version 0.1. Otherwise, they do not appear to be placing much confidence in it, meaning it's already doomed.
Ayup
maybe someone should maintain an index of software version number inflation?
feature set is much more important that version numbers. Even with products with versions 6.x, 7.x, 8.x, or even version 2009 or 2010. They can often be less stable that competing products that are still in beta, maybe even have a slower response with fixes and upgrades.
I choose the version of what ever app that has the best and more powerful next generation features.
One example with a popular open source app that I'm fond of, I use version 5.x for production stage projects but I only start new projects with version 6.x unless the projects specs happen to require a add on type feature that won't work with the 6.x version in the time frame of the project.
In another example I've went with 1.00 Release Candidate 5 (the fifth and second to last super late beta before 1.00 release, because no other competing applications had the same feature be it open source or commercial.
This has all the markers of those dodgy SpywareEliminatorUltra things that end up on SoftPedia.com
Either that, or the OP is a huge troll :)
Sometimes the first version is the only version because it does everything right.
Well Lotus must have had quite a bad run because they waited until version 123 before getting a product out there so maybe a single digit version is OK.
I worked at a place where we were developing an application for our only customer, effectively it was the equivalent of an in-house application.
Each major compile and test build incremented the build number, because we had to be able to compare the source tree against what was released as, over time, the users would be getting regularly updated packages to correct bugs and potentially add features. So the version number never changed, but the build number did. The splash screen would show the build number so when a user called in because of a problem, we could tell which package they had, depending on whether they had, say, build 803 or build 1631. (When you do rebuilds 3-4 times a day, in a year or two the numbers can really climb.)
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
You could use a number scheme like TeX. I'm sure that will fly with the PHB.
I do a lot more due diligence on a version 1.0 product than I do on a version 5.0. However, I would take any company off my recommended list if they arbitrarily decided to issue an initial release with a higher number for marketing purposes and would never come back. My recommendation would be to come out with a great name for the product and keep the numbering accurate for the sake of engineers to come.
Just release it with no version number.
DB2 never had a version 1, then went on to DB3 and DB4. DB4 was an unmitigated disaster and was the end of the line for it.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
If you're wondering if you should do this as a company, please watch Leonard Part 6, which is arguably one of the worst movies of all time.
There were never any Leonard Parts 1-5, and definitely no Leonard Part 7.
Food for thought...
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
Well, as an engineer who has been doing product management for the last eight years or so, I've certainly heard this one. Certainly, customers will be concerned about maturity. I assume with the $10K+ price tag that this is a business-to-business application. Your customers will have to go through a lot of hoops, checklists, evaluations and whatnot to purchase the product. One item on the checklist will for sure be "maturity" - having a version number greater than 1.0 might let it slide past that item - other likely items one the checklists will likely be things like "years in market", etc. - IMHO, faking a version number isn't worth the likely benefit in circumstances like that - the product manager will have to defend that in every customer meeting. Also, another quick rant - it seems like most slashdotters are assuming that the product becomes more "mature" the longer it exists and as versions progress - I'd say that for applications in this class this is not so. When you have a $10K+ app, the pressure will be very high from customers to feature fill at a quick rate - and if you want to keep the high dollar maintenance contracts coming in features will abound - quality is not likely to improve in this environment.
Do they read slashdot? Maybe they might get a clue if someone anonymously pointed them in that direction?
This is nothing new.
Remember dBASE I? Neither do I. dBASE II was the first one you could buy.
Mal-2
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Remember back when any (or most) places still accepted checks? They often would have a policy of no check numbers below 500 or 1000. So I either just requested the bank to start me at 1000 or just didn't bother using the first 500/1000 (except for paying bills).
And then my father, a smart business man who has owned/ran several businesses, pointed out that you should never start your invoice numbers at one. He always jumped to the low thousands. Just to give people the impression that it wasn't a new upstart (like it often was).
Its funny how it works. Numbers, though easy spoofed, mean a lot to people/places.
The company I work for is trying to sync all its products to the same version numbers. For example, we're soon to release version 3.4 of a product. Along with it we're combining new, never before released associated products. These products are versioned 3.4 also, because they are synced the the main 3.4 product, even though they are a brand new code base
Wasn't this the sole reason Micro$oft went from Word version 2 to version 6? They were directly competing with Word Perfect 5.2 at the time. I do know some people did think (rightly so) that Word 2 was an inferior product to Word Perfect 5.2, purely because of the lower number, so the heads at MS upped it to number 6 so that comparatively, it looked like a later, better product? As far as I'm aware, there were no public versions of 3, 4, or 5 for Word to make such a huge leap of version numbering.
BEA tried this awhile ago with their brand spankin' new 8.0 version of their server. The marketing department got clever and instead of calling it 8.0, decided it would be released as version 8.1
It might have initially fooled a few people, but it later just served as fodder to ridicule the company when we'd uncover the most basic bugs.
More importantly, their marketing department must have eventually concluded it was a bad idea, as the next version abandoned that scheme and was released as 9.0 (http://en.wikipedia.org/wiki/Weblogic)
Obviously people will want to claim that they are not influenced by silly and trivial things while operating in a business capacity. But the sad fact is that people do tend to buy for irrational reasons and they also do not buy for irrational reasons. There are all kinds of ethnic and almost spiritual locks between people. When I worked in sales I often new I had a big order as soon as hellos were exchanged with a potential buyer. Often sales have nothing to do with the price or quality of a product. To stay alive companies need to use whatever edge they stumble upon that is not immoral or illegal to push sales.
It may be more about if it is consumer fraud to ship a 1.0 app as 4.x or whatever than what it really is. 1.0. They may be able to get away with it if they offer free updates until it does EXACTLY as they promise from day 1.
It was never called "The Madness of King George III", it was called "The Madness of George III". So the marketeers were worried that Americans, unlike the British, would parse it as part three since "[First Name] [Roman Numeral]" is rarely used instead of "[First Name] [Middle Intital] [Last Name] [Roman Numeral]". The difficulty being that Americans don't think of monarchs and their naming conventions.
Your ad here. Ask me how!
While version 1.0 does have a stigmata 5.0, 7.0 or 13.0 also have stigmas of their own. Market research has shown that software with lots of numbers tend to scare off customers also. Most customers will shy away from them because they feel you'll be coming out with a new version soon, and drop support for the one they want to buy. This is why several company's have dropped revamped their numbering system (eg Adobe photoshop CS instead of 9.0). I suggest not advertising the version number of your software which is fairly common, and will make to look like less of a fool if your potential buyers actually research before they buy.
Interesting, why the arbitrary version target of 5.0-8.0? Back in the 1990s they may have suggested starting at 2.0 or 3.0 to do the same thing and imply some product maturity...
Thus I predict that by 2020, senior management types will be asking development leads to start at version 15-18 as this dodges the stigma of 10.0 releases.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Why not use the Sun model - Call it ProductX 2008 Q4 Release, Product X 2009 Q2 Release and so on.
Here you're ignoring the argument of my post, which is that you can tell whether it's good becauese you can install it for free, and test it as much as you like.
If that's your argument, then it's really weak. Why didn't you even bother to address the fact that much closed-source software (probably most) come with trials, demos, or free versions?
You argument appears to be based on a lie. Yes, I can install and test proprietary software before I commit to buy. If the software is crap, I won't buy it. Don't you think that potential sales are a good incentive for companies to write non-crap proprietary software?
... and then they built the supercollider.
As a developer I know nothing before version 3 of anything really works like it is supposed too. Third time is a charm in software. It has been true almost forever. Check the major software releases of the past thirty years and find out when they were really real. I would advise not faking it. Do it three times internally, then publically release version 4, or whatever. If you don't go through the process every user will eventually know it. If it is false labeled as a higher version, no one will reconsider it - ever. If it is not false labeled, everyone will be waiting for the upgrades - which you will need to keep going.
Better release it with 0.6,0.7,0.99a... or just beta just like google does.
...If so, it should by definition start with 2.0.
A simple search of the 'net would reveal the lack of prior versions. Personally, I would lose credibility in the company, wondering what other lies they were telling us.
Yeah version numbers are important. One thing I like about the open source software I use, the version numbers are honest -- most apps stay beta or at some 0.9 version until they're really in good shape. Distros as a whole though.. slackware for 1 did play some version number games.
Consequences? Well, when I realize your company is selling a version 1.0 product as version 7 or whatever, I will mock them soundly. But I would then evaluate it on it's own merits, and (for a high-dollar product) I'd be more concerned about how bugs will be handled if/when the pop up than if it's perfectly bug-free.
This is common though.
Solaris went to version 2.5 to 2.6 to 7.
Slackware, went from like 3 to 7.
Windows NT's *first* version was version 3.1.
WRT54G, they went from WRT54Gv4 to WRT54Gv5, with the version 5 replacing the tried'n'true Linux firmware with from scratch, buggy as all hell vxworks firmware, essentially making the whole product a v1.0 product again.
Numerous wireless cards where version 1 might be prism, version 2 atheros, version 3 Ralink, version 4 Realtek 8180, etc... essentially making each and every version actually version 1.
That's just the tip of the iceberg.
tenet, not tenant
Take a cue from Microsoft and car makers and instead of using a version number, use the number of next year. So your software product if you release it by Christmas should be called Whatever 2009. If you release it after the first of the new year, it should be called Whatever 2010. That causes people to believe that the product is something very advanced and technological. Alternately you could take a cue from Apple and name your product after some animal family. Hey just a shameless plug but check out my new website that I am putting together it's not finished yet but it will talk about the upcoming Election. With so much time left until we go to the polls. Now is the time to put together a site like it. Nothing fancy but I will try to put good information over there. It's over here.
Bah! Start at version 23.0
Instead add some adjectives to distract from the 1.0ness
ultra foobar advanced 1.0 exclusive version
*DrugCheese rants*
30% of my programs on my gentoo box are 0.*
so yeah... i have no problem with version numbers
High version numbers give me the sense the software is bloated. Take Adobe Acrobat, we're at version 9. We've all dealt with that program. 1.0 should be the _final_ product. 0.6 should be a highly stable version, 0.8 is where you play with integrating features, 0.9 is the release candidate to the final 1.0.
There's a pretty successful company that decides they'll just release all their products as "Beta," despite the expectation that it can be used commercially
D6 63 0D 70 89 81 BB 8E 7B 7C 5F 5D 54 EA AB 73
Compromise and ask marketing to call it "Captian Placeholder 2009". This way nobody lies to anybody but can still give the impression that your product is modern and fresh while providing versioning in case of later releases. Somebody seriously considering giving you so much money for software will have found out that there where no prior releases anyway and if that doesn't turn them away they probably ask themselves why you feel the need to lie to them right from the get go or how in the hell you need 6 releases to have something you are willing to actually sell.
... X] like SAP does with their netweaver family. Their first app server was "SAP Netweaver [snip] 620" and 620 can mean anything they like here.
Another route to go is to use version numbers that are not obviously in sequence [1.0
___
No power in the 'verse can stop me
... which is why when I release a 1.0 app, marketing material simply refers to it as "App Name" without a version. Coinpurse 1.0 will simply be "Coinpurse".
What your boss is doing is ridiculous. He is basically lying to his customers by saying that there have been six or seven versions of your app before then -- implying the product has undergone more on-the-field iterations than it actually has.
Customer: "You've done six versions and it's so buggy? Oh, come on."
If you have a strictly linear update model, you can get away with just about any numbering scheme you want. This is a rare situation. Usually you'll end up maintaining multiple releases, such that version 6.0 is not a strict superset of version 5.4 in terms of features and bug fixes. If your customers are smart, they'll see through any numbering games, so you should just be honest with them. If your customers are stupid, make sure you get your bonuses in cash, because there's no telling if the gravy train will last long enough for your options to be worth anything, because you're completely at the whim of the marketing gods.
It may be worthwhile to call your first beta version 1.0, and work up to a 2.0 commercial release, to appease some PHBs, but if your customers distrust you so much that management is seriously considering calling the initial release 8.0, lying to them so transparently will only make the problem worse.
Rather than making shit up like this, just call it Widget Tycoon 2009, and use build IDs for patch levels. If all goes well, you might even be able to get your customers to pay to upgrade to what would otherwise be point releases every year or two. Who wants to be running Widget Tycoon 2009 in the year 2011?
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
I am using PuTTY 0.60, but I know that putty is one of the best, not the best, but one of them. If you are making a product for non-IT people you might be better off with a release of >2.something, simply because I believe there might be a stigma (for non-IT people) for the lower versions.
One would think slashdot would prefer critical thinking over any particular value set, but oh well.
Wait, just how long have you been a /. reader? You just sounded like a newbee ;-)
Considering the fact you actually capitalized the words Open Source I just wanted to point out that such a clause would go against the Open Source Definition as published by Open Source Initiative.
More specifically Section 6. No Discrimination Against Fields of Endeavor:
Perfect is the enemy of done.
Introducing a piece of software with a version number like 5.1 is a commercial advantage.
Just wait till the (potential) buyer asks what version 5.0 or 4.0 was like in comparison to 5.1
That's the point where marketing doesn't have to answer, but someone else get to clean that mess up.
It is the usual that is familiar with people... and that is exactly what marketing is trying to bypass...
Just add "Pro" to the end of the product name, and you're done!
No version numbers needed, and instant customer confidence in your product!
No, I'm not a business consultant, but I stayed at a Holiday Inn last night.
I'm always astonished with say open source software that has been around for 10 years and is still at version 0.62 or something. I like the premise of version numbers = major changes, subversion numbers = minor changes + those features that were planned for the version but didn't make the release date and sub sub version numbers for patches. I hate when things are released and the version number is essentially just the build number without any hint of how major the changes were.
The version number, like the name sends a message about your product.
Customers care. It is just marketing. Sure it is cynical - but it really does effect public perception.
The software industry has created a convention that anything pre 1.0 is beta and therefore buggy/unstable.
They have similarly created a convention that software goes through several stages of improvement/updating as the numbers ratchet up, and that there is a difference between a 'minor version 1.1 to 1.2' and a 'major version 1.x to 2.x'.
Like any convention - marketers can use it to send messages.
I would check the software history first.
If the software history is short (in your example, it does not exist at all!) so the updates does not bring lots of fixes (if there is lots of bugs) or new features (if such are needed), I would not buy such software.
If I would really need your software, and there is no competitor, I could then buy it... mayby!
But lying for customers even in VERSION numbering... it is very stupid. I would say to your marketing people to grow up and stop lying for customers, because they are the "thing" what keeps you up and going. Play nice, be honest and respect the truth.
Even that no one cant say that how much you need to update your software, until you can change one of the X.y.z numbers, but it would be very stupid if just one "normal" feature would grow up version X+1.
I just dont trust corporations if they try to cheat me by using marketing in wrong way. It is very dirty trick and I take it as offence against me and deal is off.
These sheninigans have been pulled by software companies for over a decade. Frankly, I doubt anyone puts any credence in a version number anymore -- as the whole process is corrupt.
It used to be that 1.0 was the first version (or perhaps, even a sub 1). Now, 3.0 sounds low, so, we start at 6 or 7 (nice numbers, right?).
This disrespect to convention, has made the whole version numbering irrelevant. On top of that, some companies don't use version numbers but use names, letters, or other such monikiers.
So, who cares? Call your product Foosoft blue.
> have product version numbers lost
> all credibility and meaning?
to me, commercial software companies have lost all credibility and meaning, and that's the real problem.
I already expect that they will not deliver carefully engineered products, but throw the first thing that compiles on the market, and then just see what happens (that's v1.0). Many products are broken by design and are implemented carelessly, so they have a lot of bugs. But actually, if version 1.0 isn't good, then in all probability version 5.0 will not be much better - because you can't fix a broken design with workarounds. Version 5.0 may even be worse than 1.0 - because if the implementation is really bad, noone knows what's really going on in that code - so you may fix one error and introduce two new, more complex errors with your workaround.
On the other hand, if you can proove, that your product has a good design and is implemented correctly, I don't care about the version number - I'd even use a version 0.32 in a production environment.
Pick a sensible version numbering scheme and stick with it.
My personal favorite is x.y.z, where x is incremented at major rewrites and when incompatible changes are introduced, y is incremented when new features are added, but backward compatibility is preserved, and z is incremented for maintenance releases that don't add features and don't break compatibility (except when caused by buggy behavior, of course).
This way, you can tell that your configuration file for version 1.1.0 will work on version 1.1.1 and version 1.2.0, but not necessarily on 2.0.1, and that if someone is running 1.1.0 when 1.1.1 is already out, they may be running into bugs that have been fixed since.
Whether you, as a user, trust a given version number to represent a reliable piece of software is, of course, entirely subjective. It is wise to remember, though, that there is software with 0.6 version numbers that is rock solid, and software with 9.0 version numbers that is junk. More or less the only thing that can reliably be deducted from version numbers is that higher numbers indicate newer versions of the software. A version number doesn't say anything about how good the product is.
Please correct me if I got my facts wrong.
Who's going to be making the purchase decision on this turkey? Power users? Clueless end users? Developers? MBAs?
Generally speaking, the more technical a person's mindset is, the less stock he'll put in the version numbers.
If you're selling to developers and high-end power users, you can call it version 0.1, and they'll probably just think you're cool. But selling to technical types is a double-edged sword, because you've got to give them technical information about what it does and why its features and capabilities are superior to other products that do the same thing, or they won't be interested. Also, if they do buy it, they will keep wanting you to make the product more customizable, so they can reconfigure it to meet their needs better.
If you're selling to people with an MBA and no technical knowledge, on the other hand, the version number *does* matter. It's not the most important consideration, but it matters.
Cut that out, or I will ship you to Norilsk in a box.
We definitely need it!
Apart from slashdot geeks!!. *whiney* You're not ALLOWED to call it 7 because it's actually only version 6.34582. When asked based on it being M$ everyone nitpicks on it to such a huge degree.. then it's asked vaguely and surprise everyones acting like it doesn't matter.
Oh and the marketing guys you mentioned.. they care. Ohhh and their customers they've got this impression off..
I'm unsure why it's making your blood boil so much, they're paying you a wage, call it 'naziwarcamp3.7' if they ask.. if this act of evil is too much for your morals to handle perhaps you should quit.
... start at version 8.5 and count down!
Not a new idea.
Ashton Tate released the first version of dBase as dBaseII to give the impression it was a new product.
the same shit went on in my company. i think we developers stopped the idea by reacting in a strongly agitated way.
Do not trust this signature.
Use version number for its purpose and keep them meaningful.
Just don't let marketing mess up with the meaning of version numbers, and don't mess up marketing decisions forcing to include the version number in the name of the product. Keep the version numbers to track the product development life cycle and label your first release to the market "Product [whichever-magical-word-marketing-guys-decide]".
.... Windows 7?
I know, as a developer, that version numbers are important to controlling change, but from a marketing point of view the version number for your development process does not have to be the same as the one for use to the outside world. You know that even your own version 1.0 is really build 156.
The number shown to the outside world is marketing's job, not yours. It's just not your problem. Let them do the research and act on it.
Why not call your product "software name 2009" You can use that naming convention for a long time until your product reaches maturity. Don't make available anywhere the version number and put out a press release talking about how long the company has been in business and how much expertise they have in the area that this software is designed for.
Go tell your grandmother that she's using version 3.455.125.003.323.23 of her knitting software, will she care? No.
Ask Joe Schmo what a build number is... he won't know or even care.
Ask anyone, a computer engineer, a marketing shrew, a programmer or a VP which version of Microsoft Office Word they're using and they'll all answer 2007 or 2003 or XP or 97, etc... not 11.8202.8202.
You can give whatever version number you want, when someone comes across software that's bugged to hell they only check the version number to make sure they have the latest version installed, they don't check to see if it's a big number.
~Syberz
MS knows many people won't adopt a new OS until a a service pack is released that they put "SP1" onto Windows Server 2008 right out of the box.
Version number do matter.
This is absolutely true.
You start with a feeling and if the number doesn't jive with your feeling, you change the number, lest people have their feelings be changed by the number.
Having the version number in the product name seems to be a dangerous choice for this reason alone. I can't help but notice that this has been recently ditched by Microsoft Windows (XP, Vista)
Even when using the year instead of the version number, people lie. Everyone wants to use the next number. There are plenty of 2009 products out already.
People just seem to be predisposed to deceive with numbers. And I'm not talking about hyperbole, I'm talking about the fish story where the fisherman tells you how big the fish was, as his hands slowly move farther and farther apart.
"How big does my number have to be to be convincing but not obviously deceptive?" People will ALWAYS play this game. Anyone who has asked a teenager what time they came home last night will agree.
The costs of training and porting are, usually, far in excess of the original purchase. Even if I did not, strictly speaking, buy anything — such as in the case of free software — my investment is substantial.
Which is why I'm still mad at the KDE project for releasing an alpha-version as "4.0". And the most recent 4.1.2 (9 months later) is still no more than beta...
In Soviet Washington the swamp drains you.
First version of the database was 2.0, precisely because of that marketing logic.
Why, oh why, didn't I take the Blue Pill?
Debian will keep the 0.9 version untill the product reaches 3.0, then upgrade to 1.6, or maybe keep maintaining 0.X branch with a different name.
Rethinking email
We use SVN version numbers.
Software 15830 should be being released soon! Just as buggy as 14580 but it has a fancy platinum-style toolbar.
Ok, that's horribly Microsoft-like but it is quite possible that someone chosing between this product and someone else's 2.0, if they can't find a better reason to chose one might go with the higher version number. Not just b/c of possible bug fixes but also because having been around long enough to make a second version shows you might still be there for the next.
But... if they realize it is really just the first release... and you are calling it 6, 7, etc... I don't know about your customers but I would definately be concerned that your product is all marketing and will turn out to suck.
If you just name it for the year you aren't pushing the fact that this is the first release. But... you aren't hiding anything either.
Comment removed based on user account deletion
In my family, when a very young child (let's say 2 or less) has a birthday, we make two cakes. One for everyone to enjoy, and a smaller one specifically for the child. It's only there because the kid will want cake, but doesn't have the mental facilities yet to enjoy or appreciate the cake. So they get one of their own, so they can mess it up to their heart's desire. And if you've ever seen a young child given a cake, you'll know that within two minutes there will be no cake left-- just a mass of wet crumbs and drool scattered all about the highchair, floor, clothes, face, etc.
And that, my friend, is why you need product numbers as well as version numbers. Product numbers are what the mature, knowledgeable folk use to indicate the current revision of the software. Product numbers are what you give to the drooling simpletons in Marketing to play with. Nothing they do with it will muck up your version number. You're happy because you can accurately track your software version and honestly communicate that to knowledgeable clients. Marketing is happy because they get to feel like they're contributing something all by themselves. They'll play with it a bit, drool, probably poop themselves, then finally fall asleep from all the excitement.
Who knows, one day them might be all growed up, and will be allowed to touch the big people things.
UTF-8: There and Back Again
In my experience, I've yet to see a company (of more than a handful of users) that is willing to run out and try some new software (or new release) as soon as it is available. The stigma has less to do with the version number, and more to do with expectations that *all* software is buggy when it is first released. They delay adoption becuase they figure someone (the early adopters) will try it, find the problem, and get them addressed. When a certain amount of time has passed, or when the first patch/service pack becomes available, then they might jump on board.
I use irony whenever I can, but my shirts are still wrinkled...
...leave out the version number altogether. Just slap a "NEW!!" sticker on the box and throw it out the door. Marketing execs have spent whole careers making people think new == better. The average consumer won't even think about the version when they know it's the newest one.
And if this is the big problem at the product managers table, then start working on the patch now because you just know this thing is going to ship before it's ready.
Heh. Two separate conversations yesterday....
First, at the gym this morning. Two jocks talking about getting laptops. One bitching about Vista:
"If I knew how bad Vista was, I would have bought a mac."
The other: "My husband is so lucky, he gets to use a Mac at work. I'm stuck with Vista. I hate it, I wish I could have XP back."
Then, later on, at a presentation by our IT department about PDF files:
"We can't afford to buy Adobe Writer for everyone. There are open source solutions, which are higher quality, but our management won't let us use them. It makes my head want to explode; OpenOffice does everything we need but we have to use MS Office and Adobe Acrobat, and we can't afford to give you the tools you need."
Not exactly a ringing endorsement of closed, proprietary software?
And yes, you can write crap, as long as management is 'closed' about open source then they will buy it.
I always prefer the x.3 release of a software product. However, I believe that numbering releases misleads customers into believing that higher numbers mean more features and better quality. Take Microsoft Word, for example -- what "special" feature that one can't do without is included in version 11 that was not available in say, version 8?
Yes, OrCAD has a product "OrCAD CIS." The acronym officially stands for "Component Information System," but could easily stand for "Confidence Inspiring String." They've maintained the level of "suck" for years now, hoping you'll finally get aggravated and upgrade to the Cadence tools.
...
Speaking of OrCAD, they play the version number game. I've used the tools since they were originally introduced. v7 was rapidly upgraded through 7.1 to 7.2 for ugly bug fixes. They skipped v8 and jumped directly to v9.0. That was followed promptly by bug fixes that pushed it to v9.2. The v10.whatever releases weren't well accepted by the market. Then they jumped to v15.7, which is where we are currently licensed. Had a customer who required that release version for the drawings, so we upgraded. Funny, looks a lot like v9.2 with some cosmetic changes. We paid how much for this? and it doesn't come with paper manuals? Sheesh, what a scam. Oh looky, I see they're up to v16 now
I think you're arguing about two different things.
If a software vendor is trying to break in to a market, they give free demos, trials, etc. Once the software is established, and the changeover costs are high, then they no longer have any incentive to treat you nicely.
AutoDesk is a good example. They buy competitors and then the quality and responsiveness goes to shit. I know; I use one of their recent purchases. We no longer get bug fixes and feature updates like we used to, but we're locked in to a long-term contract so we can't change. Bingo, Autodesk no longer has any incentive to improve the product. By the time the contract is over, we will have too much in the proprietary format to change over; again, no incentive to change over.
Do you want people to buy your software or not? If so, drink the kool-aid, bub. Those marketing types are who your company hired to make the decisions around "how do we sell the most software, so we get to make more software while putting food in our mouths".
If you disagree that jumping right to v6.0 is a good way to increase sales, you should voice your opinion. This thread has provided some legitimate arguments:
* A buggy 6.0 is not a customer-retention tool
* Version numbers can look dated in the context of other products in the same space
If you just disagree on principle, you should simply call out the decision so that everyone is aware and it's a conscious decision. Don't let anyone pretend like 6.0 is a legitimate version number. Companies should own their decisions. In a meeting, with very calm and pleasant demeanor, say "Ok, just so it's clear, we're going to call this version 6.0 for marketing purposes, not for any technical reason, correct?" That way, everyone will think you had some technical reason for wanting to make that clear, and you will have called out the decision so nobody is allowed to keep pretending. Pretending is bad for morale; it's much better to be pragmatic and cop to being pragmatic.
And now that I think of it, you absolutely should either jump to 6.0 internally in your build numbering, or you should begin using some other labeling system-- if you don't, you're opening the door to Confusion, and you don't want to go there. What's the point of a version number anyway? It's to differentiate this version from previous versions. As long as you have a way to tell n+1 or n-1 (where n is the version you're using now), that's all that really matters. There are limits, after all, to the versioning system--you can't tell how many versions there are between 6.0 and 7.0, because software these days likes using lots of dots (6.5.4.1) and there's no standard as to what defines a "point release". It's whenever the dev team (or marketing) think's it's time to go up a number. :-/
Why not just suggest calling it the Gruntmaster 6000 to your PHB. And when they ask why point out because it is more advanced than the 5000 series.
There's the problem you get into next year when 7.0, 8.0 comes out and you end up doing something like "please download version 25.2" in the next decade depending on how much you like ramping numbers.
SUSE Linux started at version 4.2 for obvious geeky reasons and I think it even skipped over a couple major version numbers so that "SUSE 6.0" didn't have to try and compete with "RedHat 9.0".
The current theme with software is to give it the number of the year it was made. So your software could be "LabelPrinter 2008" or if you need the minor, "LabelPrinter 2008.1" - I think that works for everyone involved in your company, gives some false sense of security to your customers while letting them know it's not something you hacked out 8 years ago and are foisting on them (even if it is), gives a VERY large number to start from, and at least you will know when the thing was released (if you ask a customer what version they run, and they say 2008.2 and it's 2015 and your support contracts only last for 3 years, you know they can go fish)
If I'm looking for software to do a task I'm pretty familiar with (which is likely if the software is expensive, as yours appears to be), I'd be more concerned with non-1.0 software I hadn't heard of before. Yeah, new apps can be buggy, but old apps that come out of nowhere when you do a Google search or get a sales call are probably just bad. 1.0 says to me, "Hey, this is probably new (unless it's open source, then 1.0 means it's 25 years old), maybe it has some new ideas about how to do [task] better." 5.0 of something I've never heard of before says to me, "Why haven't I heard of this before? What's wrong with it?"
Earn your reputation the right way. Starting above 1.0 isn't going to do you any good.
Game... blouses.
Yes, people buy based on the number after the product name. So compromise. Use the year instead of a version number. Say that it will encourage regular upgrades. Works great as long as you can hit the target year; if you might slip into the next year though, you'll end up with egg on your face.
is competition good, or is duplication of effort bad?
My first thought, which others have echoed, is that if your software appears on the market as v6.3, a sensible person might wonder why they'd never heard of versions 1.0 - 6.2? Was it that niche, that sucky, or an in-house-only product before? Is it a name change from some other product? If so, why--to escape a bad reputation, perhaps?
These are probably not the kind of questions and hypotheses your marketers really want customers to entertain.
---dragoness
especially for enterprise software, not tech-types...
I have a somewhat unique perspective on this: I'm a DBA for a well-known company and my SO's in sales at Oracle (ERP, not tech, so there's no conflict of interest) so I know all about how they're trained to "get to the head of the dog" (we even have a cute little foam bulldog w/an Oracle logo from that class). the only problem is you live by the sword, you die by the sword: they sometimes lose deals even though the tech/finance people liked them better because the PH-CEO's golfing buddy's company uses SAP (or whoever).
so, yes, version #s probably do matter to the people who can sign contracts even if they have no clue what they're looking at...
I wouldn't buy or d/l 1.0. Now, 1.0.1 or 1.0.2, I would, after it's officially released, and the oops bugs that were missed have been found or fixed.
Calling something version 4, when there's no 1, 2, or 3, would leave me suspicious.
mark
Version 3.14159265 ?
Go go Gadget Nailgun!
Version numbers are so 1980. Just make a timeline version scheme like ubuntu, office or visual studio where ju just indicate when the product was released, like FooProduct 2008. Naming something "6.0" to begin with feels wrong. There are better ways to stay away from "1.0". As a customer I can't use a version number to determine the maturity of a commercial product anyway, so there is no need to try. What I do want however is to know which version is the latest, how old the software is ,and be able to tell from past version numbers how frequently new versions are released.
Bear in mind though, that using the year as a version number means that people may think twice about buying the product in three years.
I wouldn't be happy until the software had been through a bunch of version numbers, switched to a silly name, and then switched back to numbering again.
Why not just call it version 3008 and say it's from the fuuuuuture? Oooooo!
A) It is equivalent to our competitor's 6.3 release, so we are using that number for ease of comparison
or alternatively
A) It is an upgrade from our competitor's 6.2 release.
Remember the WinaMP3 gimmick? That was horrendous, thank God they abandoned it, skipped "Winamp 4" (for whatever reason) and started Winamp 5 based on the old, working Winamp 2.
Off topic: Nero 5.5 is the highest version of Nero I'd ever touch. Has anyone seen it lately? It went from one of the best apps to utter shit.
Isn't there a "no restrictions on fields of endeavour" clause in the Open Source definition, which prevents commercial use restrictions?
Netscape's latest official release was at 4.x, and the open source version was first going to be called Netscape 5, which would have been an incremental improvement over 4.x with shared codebase.
But then the decision was made to scrap the Netscape 5 plan and concentrate all effort on the rewrite. This eventually became Netscape 6. Sure it was new cocdebase, but it was trying to replace an existing product with pretty much the same functionality. In that case I think Netscape 6 made perfect sense - and everyone knew it was all new code anyway from the press etc.
Now I'd be much more hesitant about SomeProgramNeverHeardOf 6.0. At least I'd expect to see a list of improvements from the prior version. If I got paranoid, I might do some investigation and if I found out there were no prior version I'd think this is just a scam and walk away. And if I actually bought it, and it was not rock solid, I'd probably never buy anything from that company again.
Version 2.0... maybe I could buy a claim that version 1.0 was used internally by the company, and buggyness might not be such a huge issue. Still, I'd expect it to be pretty darn good after internal usage.
My preference: start with 1.0. Then do a 1.1 quickly, and people will be happy to come to stable version :)
As 3/4 of a million of Warhammer Online users will attest, if a company comes out with a solid 1.0 people will buy it. Specially if there is a period of public beta where people can actualy test the product.
1.0 is what I consider to be a version number of something that runs, has all the features in your original outline, and works flawlessly in all test environments. Then you do beta testing to some people.. and patch.. you may be at 1.8 or 2.0 before beta is even over.
But I work for a company that tends to do things like you are describing. It is what happens when salespeople run a company.
Lets use microsoft for example.. i bet if you went on the street and asked 10,000 random people if they knew what version number of windows they are running on their computer.. you might get 2-3 people that know. no one knows what version of windows they are running, heck i know im running vista service pack 1 but i have no idea what the build is. Most people don't even know anything past "Vista". This is a great example of how to do it correctly. Version numbers are so "1990s".
I say give your "1.x" a name, MyCoolProduct "Carrot", then 2.x could be "Broccoli" and 3.x could be "Asparagus" and someone would have to click help/about after purchasing to figure out what version and build it actually is. The business world has proven that this is the best way to do it, it gives non techies something that they can remember and spout off to make them sound smart.. and it is a heck of a lot easier to make "Carrot" look cooler on a box and website than it is to make "8.0" fancy (companies that do this tend to just make the numbers HUGE)
This is the perfect thread for an upgrade.
I suspect this is a "version 0.1" company that never dealt with real customers before.
The highest version goes up to 10 or maybe all the way up to 11.
And they mostly don't matter, but it gives the Marketing Trolls something to do, so let them play.
When get near to a final choice (say that final choice is v4) ask them if that is 4.0 or 4 or 4.00. Then font, color, italics, etc etc. This can be endless fun.
I help make software purchasing decisions for my enterprise, a large European investment bank. One of the critical factors we use in deciding to adopt a new product is how stable it is, and that in turn is based on how mature it is...and version number (or, rather, version history) is one of the key data points in determining maturity. I can tell you point-blank that starting the versioning at something greater than 0 or 1 is an instant disqualification -- it sends a HUGE signal that this product has been rushed out the door or that the vendor is for some reason trying to hide something. I have encountered holes in the version histories of products in the past, for various legitimate reasons (product was merged with another product, features were added that were so substantial they changed the nature of the product, or the product was only advancing its minor version so the major version number was dropped -- something Sun seems to do a lot) and yes, they triggered a whole lot of questions to the vendor about the actual maturity of the product. Note that the tacit assumption here is that we WILL ask for a version history, so it'll be very apparent that your product doesn't start its numbering at 0 or 1.
Starting your product at version 5.0 is a BAD IDEA.
Marketing shouldn't have any say about the version numbers. Let's take a look at the products where they did: - Weblogic 8.1 "because some company's don't buy x.0 versions" It had updates 8.1 SP1, 8.1 SP2, 8.1 SP3, ...
It turns out that those company's do their homework and just don't buy first releases.
When the released weblogic 9.0 they admitted that marketing made a mistake.
- Sun's "let's call it Java 2" adventure.
Java 1.1 was followed by Java 2 SE 1.2,
next Java 2 SE 1.3, next Java SE 1.4,
next Java 5 SE 1.5, next Java 6 SE 1.6.
Result: So Java 2 is lower then java 1.4 ?!?
Which non-java developer would actually believe that Java has an unmatched backward compatibility track record?
There is no good reason why any software version number should ever be greater than PI.
Consider the TeX typesetting program. After Knuth published version 3.14 (the fourteenth bugfix after version 3) he noticed that the value was getting close to PI. The next two bugfix versions were 3.141 and 3.1415. The current version (roughly 20 years later) is 3.141592.
It's just marketing... If you have a mainstream commercial software product for a 'non-Slashdot-reading' crowd, proper version numbering really can make a difference.
Maybe version numbering like 2008.1 is an option?
Let 'em call it whatever version number they want... here's why...
It'll be replaced by the bug-fix version of whatever crap your engineers wrote, within 6 months.
That's the overall state of the software "industry" these days.
Don't sweat it.
The only people that don't appreciate it too much are your support engineers and techs that have to talk to your customers. And they understand if your engineers ever figure out how to release bug-free code, that they don't have jobs.
Additionally, the engineers know that their only incentive is in continually releasing new software, bugs and new features included. If they don't they're out of jobs.
The whole industry is set up to churn and burn. Software has no real quality anymore unless the engineers know it's embedded and HARD to change in the field. Then they work harder on it... and it still has bugs.
Have fun!
+++OK ATH
If you start with v5.0-v8.0, you're not leaving much room for future versions. Maybe your 5th major rev is your best yet, but if it's called v13.0, everyone thinks you're just trotting out a yearly rev for upgrade fees. Sorta like a certain piece of personal finance software we all know and love.
Hao Su is a Rankmaniac
So, you can cite examples of bad proprietary software. I can cite examples of bad FOSS. It's not a strong argument.
Maybe I'm biased by my experience of software on the Mac platform, which has a thriving independent software scene, and offering generous trial periods is the norm. But I think others here are biased by their experience with Windows software, where shovelware and dodgy marketing is prevalent. For some reason Mac users do expect quality software, and a developer who releases crap generally won't make many sales. Where adware or malware is outed by the community pretty darn quick.
In any case generalizing about proprietary software based on the the most hideous of Windows shovelware is just not valid. I've had great experiences with proprietary software on the Mac, where developers often respond directly and personally to requests and problems, and constantly strive to improve their products.
... and then they built the supercollider.
Ask your pointy-haird boss to back up his assertion with data from marketing research.
No, I will not work for your startup
I think you're making my point for me. If a developer is small, has a loyal following, they will provide good service. This is true for FOSS as well as proprietary. The problem is once there is a lockin, and profit becomes a motivator, then service goes to shit. Lockin is much harder in FOSS as anyone can fork the project, so the service has to be much better.
I usually check how many versions there are. I've seen a product who was at version 0.9.something and it was in development for 2 years, most of the bugs had been sorted out and it was about to release to version 1.0. I'd use that product because I can see that they put time and effort into it. I saw another product that had been around half a year, was being fixed and was at version 6.something. I tried it, because I knew they were working on it. If I'd see a product release of 6.0 and not find previous versions mentioned I'd be more cautious because god knows how long it's been in testing and in development and it comes out under the 6.0 version. Damn that had to take some time to get everything right. Then try the product, see that there are still some major issues (and there will, trust me ;-) and have a feeling of "wtf did they do with all the previous versions?".
And tell them that it's because they're insane. Because they are insane.
www.blueapples.org
Case closed.
My only rule on Software Versions: Do not release a product version number with a lower number than an earlier release.
Why stop at version 6? Make it version 3000. That's much higher.