Slashdot Mirror
The Amazing World of Software Version Numbers
Harry writes "In theory, software version numbers should be incredibly mundane. In reality, companies have long twisted them for marketing purposes, avoided ones they didn't like, and even replaced them with things other than numbers. I've prepared a tribute to them with some facts and ruminations, but there's a lot I don't know, and I'd appreciate help on the historical side of things. (Anyone know when the standard decimal point-based system came into use?)"
What is this standard you are referring to?
Windows 7 is NT version 6.1, but that's because of appcompat reasons only.
Microsoft frequently jumps build numbers before milestones (7000 for Beta 1 of Win7, 7600 for RTM)
Microsoft often picks arbitrary numbers for revision builds (used to be buildnum.0, now it's buildnum.16384 as the starting point. Example: Vista RTM is 6000.16386, meaning there were three compiles of build 6000)
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
All I know is with Firefox on 3.5 and Windows on 7.0, Windows must be twice as good as Firefox. AOL of course trumps everyone.
My webcomic
Better late than never!
Personally I use the following numbering scheme:
major.minor.revisionXY
where the major number is 0 before the software is feature complete (based on original roadmap), 1 means feature complete, and this tends to increment when a full rewrite is done; minor are various milestones, and 'revision' are bugfix releases.
XY may be 'alpha','alpha2','alpha3', 'beta','rc1'.
So if you see a version number 0.9.3beta, you'll know it is an almost feature complete version, third bugfix but otherwise untested (beta) release. I tend to use 'alpha' if I *KNOW* there are serious bugs in the software (even if this technically not what alpha is supposed to mean).
But everyone is free to use various numbering schemes. Odd numbers for unstable releases? Go ahead, but personally I just find that a bit odd.
If you want a simpler version number scheme, just show the build number (or version control revision number) in your software.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
If one only increments the major number when you break backward compatibility, then you can get 1.10, 1.11, 1.12, etc. But I think that looks awful! It doesn't sort right in text anymore, and 1.01.5 isn't going to make any friends.
I remember when MAME was hovering around the 0.97 mark and the user forums were asking if this meant that in 3 version's time MAME would hit version 1.0. The answer came back as no because that would mean that it was complete and MAME is nowhere near completed. Instead it went from 0.99 to 0.100.
(That's a period denoting the end of the sentence, not part of the version number in case anyone was confused.)
Summation 2
The proper way to use version numbers is to continually improve the precision of an irrational number, as in Tex.
don't forget to upgrade to:
V0.1 Basic - you don't really want this cuz we crippled it so you would buy our more expensive packages
V0.1 Premium - just enough of a taste to make you horny for more features in our Platinum package
V0.1 Professional - we stripped out some the the cool stuff and added some features for buisness that you will never use
V0.1 Platinum - this is the best one yet! you get everything!(almost) it will even make you coffee and pancakes and walk your dog!
V0.1 So awesome we can't even tell you the name edition! - we don't know what the hell this is, our marketing guys have been hitting the sauce pretty hard lately.
I've been working for ISVs for nearly 25 years, and for some reason have developed a "thing" about prime build numbers. It got to be a running gag at a couple of places I worked, to the point where at one place the buildmaster would bump the build number to the next prime number for the "gold" build.
Nice to know I'm not the only one with build number quirks..
Well, decimal version numbers in their current form go all the way back at least to MS-DOS, so that would be 1982 (if not earlier). It used X.Y version numbers, eg. 2.1, 3.0, 3.1, with the now-common interpretation of the major versio number meaning significant new features were added and the minor version meaning fixes or enhancements to existing features but nothing major new or changed. I'm pretty sure the convention wasn't new with DOS, it probably goes back even further to the mainframe world.
Ubuntu using the year and month for version numbers is a great idea, then at a glance you can see when the distro was released, after any application or operating system makes it to a 1.0 release it should be done this way = YY.MM
The crap that microsoft does is just exactly what i see in versions, versions like home basic, premium, ultimate just sounds like marketing cruft, when we all know the OS was originally built with ALL the features and all they did was cripple it in steps and named them as such, so in essence the "basic" should cost the most because more work went in to it to remove the features and extra testing went to to make sure it still worked good enough to market...
Politics is Treachery, Religion is Brainwashing
All TIFF files have a version number of 42, chosen, according to the developer docs, for that number's deep philosophical significance.
Software versioning gets really confusing with game programming, specifically versions vs. sequels. Zelda II and Mario II are sequels of the original - very different games. However, Quake 3 is more like a version difference from Quake 2, even though technically it's a "sequel". Windows 7 is definitely a version difference even though it wants to be a sequel. The difference? Because they are different, people understand why they should pay for sequels, while they want the less-different version upgrades for less/free.
stuff |
The article mentions OS X and the fact that they will be running out of cat names pretty soon.
My prediction: as soon as they run out of cat names, they'll go to 'OS 11'
Steve Jobs will market it by saying 'this one goes to eleven... It's one better, isn't it?'
XBox 2 through 359?
Nintendo 2 through 63?
Windows 99 through 1999?
Kenny A through F?
Nothing will beat the Clipper version system... Everytime I used the Summer 87 edition, my mind would conjure up images of a schooner slicing through the chop in Nantucket Sound, with a bikini clad blonde bombshell sunning herself on the bow... ahhhhh...
And then someone who hadn't bathed in 3 or 4 days would lean over me at my IBM PC XT computer and ask me for help in compressing an index. Daydream explodes.
Brawndo: It's what plants crave!
Step 1: v0.1 Beta
Step 2: ???
Step 3: PROFIT!
Porquoi?
I prefer to just go with a year.mo.da system. Mark it as beta if needed. Its very easy to see when an application got updated or released then or to see if it needs updating and it makes sense to a layperson
Version numbers like this ... -> 0.8 -> 0.9 -> 0.10 -> ... are the worst bunch of them all.
Those who number their software like this might argue that the numbers are mutually exclusive, "that's a major number, that's a minor number, that's a whatever the hell number". Look, I see numbers and I see decimal points, so I expect them to follow some kind of order. And 0.10 is not greater than 0.9. I don't want to read a paragraph long explanation or justification about your version numbers. It's a fucking version number. There should be no need to read a man page to understand them.
If you're going to use decimal or decimal-like notation, the next version should be 1.0. If it's not ready for a "1.0 release", then just tack on another number 0.91 or 0.9.1. Is that too much? Seriously, is that so hard? Why cause unnecessary confusion among users by going to 0.10?
My favorite has always been Oracle. The first commercial release of their flagship DB was version 2.0. There wasn't a version 1 because they wanted the product to sound more mature.
If you post as Anonymous Coward, don't expect a reply.
Version numbers is about communication and it doesn't matter one bit how fancy your system is if it's not communicated and understood by the intended recipiants. That can be things like API compatibility, binary compatibility, scope of UI/feature/fix changes or just the time of year (Ubuntu version numbers, anyone?) - there's really only one cardinal sin, and that's releasing something with an version number that doesn't correspond to the expectations. I don't mean version number nazis that insist you can't have an RC if you know it'll need another patch, but real mismatches that mislead users. Everything else is either bonus or useless fluff.
Live today, because you never know what tomorrow brings
The article mentions bits about the lack of marketing pressure in the FOSS world keep the version numbers sane. Since many FOSS programs have often been forked for direction/feature/standards reasons, and this is the same kinds of changes meriting new version identifiers in commercial software, perhaps that premise is flawed. Sure, those projects might make significant changes and increment the major version number, but the ability to fork and work on the features and changes you want is the source of the wonderfully full FOSS ecosystem. Commercial software companies might learn a thing or two from this. There are tons of forked projects where the original and many of the forked versions are still being used. Not sure how to monetize that process though.
I'm not sure if the step in Word for Windows version numbers really was because of WordPerfect. Prior to 6.0, Microsoft had two independent Word release series: The original Word running on DOS, which already had reached version 5, and Word for Windows, which only had reached version 2. With Word 6, the DOS and Windows version numbers got synchronized; since 5 was the latest DOS version number, it made sense to use 6 next.
The Tao of math: The numbers you can count are not the real numbers.
Well, that's 4 minutes of my life I'll never get back. Chrissssst... I'm a geek and even I thought that was dull.
Smokey, this is not 'Nam, this is bowling. There are rules.
I'm used to the major.minor.patchlevel scheme. But the choice of what's patch/major/minor shouldn't be arbitrary.
Patchlevel is just for bugfixes. So for libraries, they should just be able to drop the new one in,
or relink (static libs). For programs, the user shouldn't see any difference (besides missing bugs,
or better performance).
A Minor version bump implies that there's a new feature. So for libs, someone using this feature
can't make do with an older Minor version. Otherwise, this is a drop-in replacement, just like
patchlevel
A Major version bump implies binary incompatibility. For a library, this implies that your users
need to re-compile against it, and possibly change the way they call it. For a program, the network
and disk storage formats have changed, and they may not be able use it with data from older versions.
Just this past week, in order to maintain some rpm repositories from multiple sources, I needed to discard versions of a package older than the most recent. What a pain (think about it ... mixed alphanumeric, usually numeric, but needing to sort numeric on arbitrary decimal and - boundaries).
Luckily I discovered the Sort::Version perl module. *whew*!
Another interesting version number case occured during the gcc/egcs split: The egcs releases had two version numbers for the same release: One starting with 1.0.0, numbering the egcs releases, and the other one, IIRC starting with 2.91.0, giving a "gcc version number" to indicate that it was still considered to belong into the gcc family. After egcs officially bacame gcc again, the first releases had the form 2.95.x before the 3.0.0 release came out (starting from which the numbering followed the normal schemes again).
As an additional twist, before it was decided to name the next release 3.0.0, the internal development code had the version 2.96.0, which also was used for a Red Hat gcc release. There never was an official gcc-2.96 release, though.
The Tao of math: The numbers you can count are not the real numbers.
I'm not sure what the previous versions were called, but Google's Android OS recently released Cupcake. Next up is apparently Donut, then Eclair, then Flan.
I think one of my favorites has always been the common "binutils" package in Linux. Looks like the last release was binutils-2.19.51.0.11 I don't remember ever seeing anything but a 0 in that 4th number, but it's always been there.
One reason marketers have given products names instead of numbers, which isn't mentioned in the article, is that courts have ruled that companies can't trademark numbers (though I can't find a source reference).
No mention of TeX version numbering? (Asymptotically approaching pi?) RTFA
A.B.C.D
A: Major Release, violates backwards compatability
B: Feature Add Increment. Indicates new features from prior release
C: Bug Fix Release Increment.
D: Build Identifier usually YEARMONTHDATE
e.g.
1.1.0.080215
1.2.12.090714 (12th minor update to feature set 2 for release 1 built on July 14th 2009)
1.3.1.091224 (First minor update for feature set 3 built on Dec 24th 2009.)
Since most software tends to follow quarterly or monthly release schedules you rarely get more then 18 minor revisions if they are building weekly on a quarterly schedule or more then 4 on a monthly schedule.
-=[ Who Is John Galt? ]=-
How can you omit Oracle? The first version was 2.0.
Has anyone seen another program admit they screwed up and go backwards?
I purchased the old shareware database program PC-File (and still use it!) Not sure of the 1st versions, i don't think it had a number. 2nd one i got was version 5 and was a good program that could have used a few tweaks but was fast and simple. Version 6 changed drasticly and many functions got slow as it tried to go to a pretty UI. Version 7 tried to fix version 7 but was still sluggish. The next version released was.....version 5.5! They tried to fix up the old one by adding a couple needed features but missed a couple others. I think he sold out or moved on at that point and it faded away.
It was simple and fast enough that i used it for looking up names and other info from a barcode in real time into a database as fast as i could scan in labels on a 386 :) Ok, i did need 10M of ram so it could use a ramdisk since the HD couldn't keep up.
Didn't see him include 5,6,7,5.5 in the article :)
No mention of TeX version numbering? (Asymptotically approaching pi?)
Err.... You *did* realize there were three pages in the article ? TeX is at the bottom of page 2.
-- don't discount flying pigs until you have good air defense
I dare anyone to deconstruct the Actiontec MI424WR router versioning scheme:
Currently firmware version is 4.0.16.1.56.0.10.11.6
http://opensource.actiontec.com/
Version 1 - Buggy as all heck - maybe 20% of users get it working.
Version 2 - Major bugs fixed - leading edge users adopt and love.
Version 3 - The sweet spot
Version 4 - Major enhancements - most don't work. Core functionality still works
Version 5 and above - Bloatware
For my own stuff at one point, I automated the version numbering based on dates. I would set the first year as the "epoch" for 1.0 and munge the day into the minor number. This was before I started working in an environment with a revision control system.
Later, I would have my programs output their revision numbers. (There are Subversion hacks combined with your makefiles that make this fairly easy).
Of course, in the corporate world there is always some agreed-upon version number that has nothing to do with the svnversion of your component. In my code, for an application named foo, I'd have the svnversion defined as FOO_SVN_VERSION and the other number would be FOO_MARKETING_VERSION.
If you ran foo --help, you got something lik:
Foo version 2.1, (C) 2007 Fubar Company. Revision 2345.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
One of my favorite version numbers was the version of the first Doom II executable (which used a different version number than the game itself as it shared the exact same executable with Doom I, Doom I shareware, and Doom II). The initial release of Doom II was "Doom II Version 1.666"".
"Never trust/buy a x.0 version" .0 version more often than not was a "it compiles, ship it" version. If you were smart, you waited for .2. Kinda like you wait for SP2 today.
Sounds familiar? Of course. And with good reason, a
What did companies do? They offered a .0 version for a week or two, immediately followed by the "final final" .2 version. I wouldn't be surprised if we could soon only buy SP2 versions of some new OS.
The first signs are already there. Or did you get a WinXP version that didn't include a SP1?
In contrast, you'll be hard pressed to find anything (but core parts) for Linux that isn't available in a "0.x" version. A 1.0 for Linux is some kind of event, usually coming long, long after it has become stable and useable. IMO, when judging Linux programs, shift that dot to the right by a digit and you're where you would be in commercial software.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
My favorite version # memory is Winamp 5. The best of Winamp 2 + Winamp 3 combined.
"Persistence is annoying success." - ghee22 11:28:1999 - 10:53:PM
I'm both shocked and appalled that the article made no mention of Web 2.0 as the absolute *worst* abuse of version numbers.
Oh well.
This is one of the most irritating things about working in Ruby. Most of the people writing gems don't seem to have ever learned version numbering conventions, so it's not at all uncommon to have a point release (e.g., 1.1.2 -> 1.1.3) that breaks API compatibility. The Merb folks have been the worst offenders, in my experience.
The most irritating thing about this is that the documentation for the gem system has an entire section devoted to version numbers. It very clearly explains the major/minor/bug fix convention. Evidently nobody has read it.
The author of the article states that he doesn't know why we are on StarOffice 9 yet OpenOffice 3, when they are the same suite. Let me help.
StarDivision created StarOffice. They eventually sold StarOffice to Sun. When Sun released StarOffice 5.2, they open sourced it. This created OpenOffice. OpenOffice then had trademark issues and changed it's name to OpenOffice.org.
OOo released 1. Sun rebranded it as StarOffice 6.
OOo released 1.1. Sun rebranded it as StarOffice 7.
OOo released 2. Sun rebranded it as StarOffice 8.
OOo released 3. Sun rebranded it as StarOffice 9.
By "rebranded", I mean they added some stuff with addition to rebranding.
This is similar to Apache Tomcat and IBM WebSphere and JBoss, except in this case the rebranding adds far more to the base product.
It's only somewhat arbitrary
:(){
...personal encounter with a second decimal point in a version number. Although I was just a high school kid at the time I can still remember all the geeks on the other side of the Mac/PC divide claiming it was aberrant and wrong.
Thus my general disrespect for proponents of the Windows operating system was born.
The article states,
Did Windows 95 start the idea of using years instead of version numbers?
Nope -- it's a far older conceit than that. The earliest example I'm aware of is Fortran 66 ...
I believe Algol 60 predated that by a good 6 years, and Algol 58 by an additional two. While Algol 58 didn't see as wide usage, Algol 60 was, to many, the definitive version of that language.
See http://en.wikipedia.org/wiki/ALGOL
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
KDE 4.0, Amarok 2.0, and now Koffice 2.0 were all developer releases. KDEHater had a great writeup here:
http://kdehater.blogspot.com/2009/06/koffice-two-point-oh-no.html
Thank for reading to the sig. You may stop reading now. It is safe. There is no more content. Why are you still reading?
I don't know what is the highest version number ever, but I know that it is bigger than 23.
The latest stable release of the unix programm "less" is 429.
Apple will have even more names when they move into LOLCAT space: Serious Cat, Ceiling Cat, Basement Cat, Itty Bitty Kitty Commiteh, and Monorail Cat.
The possibilities are endless!
I love the sound of distortion in the morning -- webcommando
You may have missed that the article contains three pages. The second page mentions the TeX version numbering (section "Is there a funniest version number of all time?")
This one indeed seems to be missing.
The Tao of math: The numbers you can count are not the real numbers.
Possibly because he fears that trying to explain them will cause a brain hemmorage.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
The article asks "has anyone ever been brave enough to sell a version 13 of anything?"
There was AutoCAD Release 13 back in the day.
4.0.16 is the software version
the rest of the numbers are security and protocol versions built into it.
We hardly read articles. You think that when we do, we do it well?
Matlab is my favorite for bizaar version numbers. I have for example Maltab Version 7.0.1.24704 (R14) Service Pack 1.
Not only does it have the standard Major.minor.bugfix numeric structure, but it has a marketed Release number (R14) AND it has a Microsoft style Service Pack number AND it has an automated build number!?!
Makes you wonder how they all relate to one another.
This whole subject has sparked a huge debate in the Java community over the proposed specification for Java modules (basically OSGi, but with language support and entirely incompatible.) Google for "JSR 277 controversy" and you'll find plenty of forum threads and articles with everyone arguing for their own version numbering scheme. The developers of the spec claim to have done a fairly exhaustive survey of real-world version numbering, but then seem to have chosen to standardize the version numbering used at Sun, which has caused a bit of an uproar. The only thing that has been agreed upon is that there really isn't one versioning scheme that everyone can agree on.
The main issue, as I understand it, is finding a versioning scheme that allows for automatic sorting to allow fuzzy dependencies (i.e. version 3.5 or later.) In theory, this sounds like a great thing and one that should be easy to accomplish. And it is simple for any one versioning scheme. But when you hit real-world usage, things start to get complex.
"Don't blame me, I voted for Kodos!"
Err.... You *did* realize there were three pages in the article ? TeX is at the bottom of page 2.
??? Maybe someone can explain to me how this 'page numbering' system works.
This guy's the limit!
We use odd numbers only for our major releases. When I finally asked about that, I was told, "Someone didn't like odd-numbered releases." And that's why I love my job.
From the article, "...the highest version number I know of belongs to Broderbund's The Print Shop 23..."
Emacs' next version will be 23. Let the race begin!
I'm I the only one to notice that windows jumped from version 3 to 7 much like the american adaptations of Final Fantasy?
Look forward to Windows 7: Crisis Core, If you survive Windows 7: Dirge of Clippy
But... the future refused to change.
Explain 6000.16385, then.
That's the build I got for review purposes from Microsoft, and based on what I know, gncaddict is correct.16384 started as zero, followed by increments per revision. 16385 was handed to press, and 16386 was signed off.
I release several games as custom maps in Starcraft. Many of them are refinements of earlier versions made by others. And all of them are released unprotected so that others may add their own refinements.
Version numbers get messy. I typically go to the next major number if I'm doing a serious overhaul of my own or somebody else's map. Then I increment the minor numbers for bug fixes, balance changes, and minor enhancements.
But then somebody else comes along, makes a minor (and often terrible) change and releases it as the next major version. Or they make major changes and release it as the next minor version. Then when I make a new version, it either clashes with those other versions or looks older than the versions released with big jumps.
I've tried adding descriptor names to my versions, a la Vista. So I have "Phantom BGH Gold 1.0" as my refinement of "Phantom BGH 2.4", but most people don't seem to get that. When my updates landed me at "Phantom BGH Gold 3.0" people at least paid attention that it might be newer, but they still complained that it was different than "Phantom BGH 2.4".
I also tried adding "Classic" to a game version which was a totally rewritten implementation of a game type with other versions in the 3.0 to 9.0 range. I intended the "Classic" to signify I was focusing on the core ideas of the game type, but so many people thought it meant "old". As if the first version ever released of that map was labeled "Classic", and a label of "New" means new forever.
TheNevermind
Super Cool Edition
When Business Objects released version 11 of its software, the Marketing team got a hold of it and dubbed the version XI, for "Extreme Insight". Since then, they haven't let the XI go, so the next release became XI R2. The next release was planned to be XI R3, but then Business Objects got bought by SAP, which already has a product called R3. So the release was rebranded as XI 3.0, which is really version 14 of the suite. Perfectly clear, right?
I would bet that you could trace the origins of software version numbers even through the 1960s, because they had two blocks of Apollo spacecraft, block 1 and block 2.
This is my sig.
openSUSE has its version numbers due to marketing, or at least somewhat.
SLE goes 8, 9, 10, 11, 12. openSUSE goes around that. In general the version just befor a new SLE is X.0, the ones after that X.1 S.2 and so on, till they start with the Y.0.
The whole process of development is continues.
The strange thing is that many people still think that the X.0 is beta and will wait for X.1. I have seen differences that are huge between e.g. X.1 and X.2 and minor differences between X.3 and Y.0 and it has been confirmed by SUSE people that the numbering in itself means nothing in a technical sense.
Don't fight for your country, if your country does not fight for you.
In software versions, all the numbers are awful.
Ignorance is the root of all evil.
And if there's ever an OS X release that has a really bad bug, one that causes users to scream and swear as soon as they see it, I predict it'll get a new nickname.
Two interesting versioning scheme that I think of:
:-) (Directly copied from http://pauillac.inria.fr/cdrom/www/SmallEiffel/man/SmallEiffelFAQ.html#Q02 )
TeX 3: Updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.1415926 (Directly copied from http://en.wikipedia.org/wiki/TeX)
SmallEiffel (predecessor of SmartEiffel, which used a boring versioning scheme): Version numbering uses negative numbers. The first distributed version was numbered -0.99 ("minus 0.99"), the second one -0.98, the third -0.97, and so on. Version number 0.0 should be an opportunity for celebration
Engineers usually have a legit reason to brand a public version number... the next release, and the number indicates the level of importance. So far, so good.
But then marketing and politics get into play.. and if you're in the business, these are good things to know. Sometimes it's just marketing... the DECT cordless phone standard somehow mutated version 1.6 into version 6... I guess that sounds more grown up in the marketplace. But it's also the first time they were using "DECT" as a buzzword in their marketing. No harm, no foul.
Other times, it's keeping up with the joneses. Some have a method to their madness.. I use lots of Sony Media Software tools... you pay once for any major version, all of the minor versions in that release are free updates.. not just bug fixes, sometimes including new features. New one comes out, you can decide to upgrade or not... if you skip a version, you still get an upgrade price on the one after that. I'm really happy with the way these guys do business.
At other times, something as stupid as a version number can become a billion-dollar weapon. This only happens when idiots are involved in contract law, I think, but it's happened. My classic example: MacOS and the open Mac platform. I was designing this kind of hardware in 1996-1997, the PReP, I mean CHRP, er, umm, I mean PPCP standard for Mac compatibility. This was largely at the urging of Apple's CHRP (um.. whatever) group, whom we (PIOS Computer AG, Hildesheim, Germany) met with in January of '97.
So, like Power Computing, UMAX, IBM, Motorola, and others, we're off making a standard PowerPC platform machine. Maybe it should have been clear, after meeting at Apple and seeing that a Mot Starmax they had on-hand was the fastest Mac every recorded... at this side of an Amiga 3000 running a Mac emulator (a previous project of mine... the A3K, not the Mac emulator). Jobsie wouldn't like this, would he?
So Jobs comes back, and like magic, at the Mac Conference in September, they announce MacOS 8... which is MacOS 7.6.something with a new name. And guess what... Motorola and IBM, the two big, old-school, real serious companies with more lawyers than PIOS Computer had employees (by some orders of magnitude, I suspect) had left a huge, ugly, gaping hole in the contracts they negotiated with Apple for MacOS... Apple gets to renegotiate the contract, completely and totally, on major revisions of the OS. But they get to decide the definiton of a major release of the OS!
They didn't really cancel MacOS licensing then.. I don't think even IBM and Motorola were stupid enough to have allowed that. But it was only a small functional difference... Apple was going to licence MacOS based on the CPU in the box.. the faster, the more expensive. My little startup had produced the first full systems shipping at 300MHz (there may have been "accelerator boards" before then, but we integrated the system... we bought motherboards from UMAX and designed our own CPU cards)... that would have been something like $500 per MacOS version to license, despite the fact you could buy it off-the-shelf for like $75.
I think this is also a good lesson for any engineer allowing lawyers to do things that have major impact on their future business course. Nothing I could have done about this, but after losing something like $100 million on the while Mac Clone thing, one would hope Motorola learned that hard-bought lesson. I do note they have "literally hundreds" of engineers working on Android-based cell phone stuff. Yeah, that ought to be a bit safer...
-Dave Haynie
OS 2200, for UNISYS mainframes, is somewhere around Level 48 today. The original demo release was April 4, 1967. Level 23 was reached around 1970, level 32 around 1978, and level 48 in 2007. Builds have numbers like "26.51.465".
Yes, there really is an operating system over 40 years old in current production use.
Algor rolled out version v23.1 in February. http://algor.com/software_services/whatsnew.enu.htm V24 will likely be out later this year. There's must be software packages with even higher numbers.
The world is made by those who show up for the job.
Oddly enough, the Dewey Decimal System is at v22, no decimal.
Set your phasers on "funky"!
But what about when you start dealing with a large collection of derivations - be it code difference, option difference or compiler difference. This is where true configuration management comes in. The version is for the code, the configuration is the instance.
The Linux kernel shows a good indication of this. The *upstream* kernel versions more or less match what you are saying. The *downstream* kernel versions begin to blow up into a mind-numbing collection of derivations. You have -bigmem, -smp, -10-1. Each one representing a variant of some sort from the original code. Even the -hugemen/-bigmem/-smp variants are just options over the same codebase.
We were using x.y.z, at first in a fairly undefined manner, and then sometime around 1973-1974 an edict came down from Armonk that defined the rules as follows:
The scheme is version.release.level, where
Version - major functional upgrade, permits change in price and/or change in name and product ordering number
Release - useful new function(s), no change in price or name of product number
Level - bug roll-up, minor new function
There were also differences in how many hoops the developers had to jump through to get the product/version/release out the door, so very soon lots of teams were shipping major new function as Levels - guess how much the bean counters liked that!
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
See the "-v" option to gnu ls(1). If your other applications can't cope, that's because they're broken and/or inferior.
Anyway, you have the same problem when you go from version 9 to version 10. If you're simply using a text sort, emacs v22 will come just before the ancient v3.
Was 2.0 twice as good?
Gold, Platinum, Platinum Plus were all substitutes for proper versioning in the 1980s and probably 1990s. This is parodied by many a perl script,
$ua->agent("Schmozilla/v9.14 Platinum"); # give it time, it'll get there
This was not as arbitrary as one might think. Toward the end of NS4's actual development cycle, there was an attempt to wring another major version out of that codebase, and it was called Mozilla 5. Eventually it was abandoned because the new NGLayout engine (now known as Gecko) was much better than the clunky old Mosaic-derived codebase. The NG stuff became the basis for Netscape versions 6 through 8, the Mozilla Suite, Firefox, Thunderbird, and lots of other things.
I know there are some Netscape/Mozilla folks around here who could correct/expand that story.
Microsoft's numbering can be a little confusing. Obviously Windows 95 was the 95th version and Windows 2000 is the 2000th version. XP stood for "eXPonential" which was a big jump from 2000. So how the hell are they now on version 7?
New feature in Ceiling Cat: Incognito mode?
What is your postal address? I would like to send you a large sack by mail.
The Python team should follow this philosophy, what I have seen of Python 3 fill me with WTF.
Get rid of the string formatting standard that everyone uses? WTF? What good is that, it only makes it harder to migrate from C. Get rid of functions like system and popen, replaced by a Popen function which needs six or seven arguments? Get rid of tuple arguments in functions? Get rid of functions that return lists? WTF? Where has the simplicity and ease of use gone?
Why get rid of so many useful features, just for the sake of some computer "scientists" who, very obviously, have never done any professional programming? "The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5." .
I wish Guido van Rossum took a hint from Donald Ervin Knuth (a guy whose name is an anagram for "hunt, drink, and love" cannot be all bad...) and TeX and would create a traditional Python with all the excellent features the language had until version 2.5. My suggestion: call it version 2.718281828459045...
Slackware Linux skipped from 4.0 to 7.0, because they wanted number parity with RedHat and other popular distros.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Apple's recommendations from the classic Mac OS days (as explained in Technote OV 12 -- Version Territory, now #1132) were what I grew up with.
* First released version: 1.0
* First revision: 1.1
* First bug fix to the first revision: 1.1.1
* First major revision or rewrite: 2.0
The important part of version numbers is comparing them, and that's another place where Apple's classic metadata resource framework was ahead of its time.
Years later Apple chucked many of these recommendations with QuickTime/iTunes version inflation. But it's nice to see things have stabilized somewhat in that regard. QT7 and iTunes8 have had lots of revs.
Hire a Linux system administrator, systems engineer,
Some gradebook program my school used to use ("used to" is the operative word here) broke backwards *and* forwards compatibility. When incrementing from 3.2 to 3.4.1. Thus, there were two incompatible gradebook programs under the same brand with the same version number.
Thankfully we have since moved to server apps hosted on the school's local appserver (and accessed through a browser, of course).
Note: I was 13 when I wrote most of this. Take with several grains of salt.
as a business-conscious engineer, i'm well aware of the business/marketing reasons for wanting to tweak or set the version numbers. in the commercial world, sadly, these things do actually have impact, so i'm willing to trust people with more experience than me in such psychological fields to have their input. what kills me is when they don't realize that there's actually valid technical reasons for version identifiers, too.
.0 releases". so then it became "er, make it 3.0, 3.1, 4.0, 5.0, 5.1....". the numbers got more divorced from any technical input. but at this point, marketing had already started printing literature with version numbers in it, and promising clients "3.2" on a given date, and so on.
at my last company, i was part of the new R&D department intended to make us no longer reliant on 3rd party contractors and consultants (which had been going poorly for us). we had multiple product lines with no coherence between any names and numbers. we had a product retroactively named Phase 2, an unrelated product retroactively named Phase 3, and its successor named Phase 3 Version 3, all with what amounted to point releases, without any identified version numbers or names. it was often just difficult to tell what we were talking about.
so when we started working on our own stuff, we did better. we went "major.minor (build)". the head of marketing made a compelling case for being able to decide what was "major" and what was "minor" as far as our clients were concerned, and we thought that was fine. when we were on, say, version 2, we'd have a roadmap for the next several feature/fix packages and say "we think this bundle is version 2.1, this next one is 3.0, then 3.1, 3.2, 4.0". we went 2-5 feature/fix bundles into the future. marketing would come back and say something like "we really need a major-number release earlier than some trade show; make that 3.1, 4.0, and 4.1". some of the engineers were unhappy with this, but i think that's mostly because they discount the validity of marketing and psychology in commercial enterprises generally. in reality, it worked fine.
for about 4 months. then the marketing guys decided to start changing things. frequently. they'd discover some other show they needed to get to, or decide one was less important, or a customer would tell them (stupidly) "we're going to wait for the next major version" or "we don't trust
the biggest problem for engineering was that, again, it was hard to know what we're talking about. when we met to discuss the feature set to put in 3.2, or the planning for 4.0, which 3.2 was that? no good. so we gave up, told marketing that they could simply have the version number all to themselves, and we came up with a unique identifier series to use ourselves: each feature/fix bundle got a volcano name. we could talk about the features in Koko, or decide Krakatoa was too big and break it into Deccan Traps and Viti. we got everyone - including the head of marketing and the CEO - to agree that these were internal-only, engineering-defined designations for feature sets, not tied to published version numbers or whatnot. marketing got nice numbers to show clients, we got reliable, unambiguous identifiers. worked great.
for a little under two years. then we had a review release for the "Kick 'em Jenny" release, where the head of marketing (yes, same one) "asked" us to change the name. R&D had been using it for about six months, so this was reintroducing the same problem we'd invented them to fight off, so, as the engineering manager on the project, i wasn't happy to see this happening, and asked why.
"well," he says, "we can't very well tell that to clients."
"er, right. that's half the point. these are engineering names, remember?" i responded.
"yes, well, the clients like to know the names. we've been telling them all the earlier ones."
(elided arguing and frustration on all sides)
"okay, okay." i said. "a month or two ago, actually, they discovered a near neighbor to Ki
i speak for myself and those who like what i say.
I rather like Ubuntu's YY.MM numbering. It's objective and totally clear.
From the article:
"I wish I could tell you actually, I'm hoping that someone reading this will be able to. I do know that the FORTRAN II programming language came along in 1958,"
Tiglath Pileser II was King of Assyria from 967 BCE to 935 BCE (due to a peculiar way Assyrians had of counting).
Of course if you want to include Windows ME and CE, then you may want to consider Dumuzid, the Shepherd, "who is not to be confused with Dumuzid, the Fisherman". He was was the 5th pre-dynastic king on the Sumerian king list (before ca. 2900 BCE)
We need a "+1 -- nice sig" moderation.
I first became aware of version numbers in hardware. Specifically, the Nikon F competed against the Canon F1. So Nikon introduced the F2. Then Canon came up with a new model that should logically be called the F2...only they couldn't name it the same as the Nikon. So they called it the "New F1". Nikon proceeded to come out with F-series machine up through F6. Canon abandoned the nomenclature and, with the next big design leap, introduced the EOS line. I always thought that stuff was fascinating.
All engineering logic gets tossed when it gets in the way of marketing, apparently. It doesn't matter if it's software or hardware, that's a near-universal truth.
A.B.C.D
A: Major Release, really freaking hard. Will probably deprive you of sleep for a day or two. Start with backups, and test the backups before you bother.
B: Minor Release. Probably will not hork your computer, but will randomly do so.
C: Some number that I pretty much ignore.
D: LOL Wut?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The correct way to version your software (according to M$) is: ,3.11 , 95, 95 osr2, 98, 98se, ME : if it runs on DOS.
1.0, 1.x, 2.0, 2.x, 3.0, 3.1
OR
3.0, 3.1, 3.5, 4.0, 2000, XP, 2003, Vista, 2008, 7 : if it NT based.
See it is all so clear....(did I miss any?)
What I don't like is when they release a product using the "Some program for windows v3", does that mean it only runs on win 3, or is it v3 of the software.
Australia (and Asia, and incresingly the worlds) most popular schematic and PCB design software has had a colourful upgrade path.
It was originally just called Protel (DOS days) (Now Protel for DOS)
then...
Protel 98
Protel 99
Protel 99SE
Protel DXP
Altium Designer 6.0
Altium Designer 2004
Altium Designer Summer 08 (Winter in northerm hemisphere even though its developed in Australia)
Altium Designer Winter 09
gotta love marketing..
46137
First Post 5.2 SP2 Build 23543 FixPack11 HotFix#3243
The usable version
I've lead many development teams. Marketing almost always selects what goes into a x.y release and developers choose what goes in every x.y.z release.
Since marketing and sales was so involved in all the development stuff, my team started using build numbers. Build numbers were:
a) guaranteed to be unique
b) always increased for a product version
c) left room for older version builds to have fix builds when the new development was on a new branch
For my teams, x.y.z releases that changed just the 'z' part were library compatible. You could swap a shared library or DLL and not have any issue. Any new public conf/ini settings may not have the final default setting. New extensions may require odd settings to have them enabled. Most clients won't be told about a new extension.
When the 'y' part changed, internally built libraries may or may not have changed. If you knew the internals, you could safely swap certain DLLs.
If the 'x' part changed, 3rd party commercial tools may or may not have changed. A fresh install is highly recommended for the application.
System version numbers meant nothing to me other than a bonus check. Follow the build number.
Winamp was a small, great, fast and reliable MP3 player. It was, up to version 2.95. Then they started version 3, which was waaay slower, with new eye candy and crossfader. Nobody actually used it, so they got the UI of version 3, tried to catch up with version 2's speed and reliability and made it Winamp 5 (2+3 = 5).
The article seemed to miss a form of version numbers: YYYYMMDD. Sometimes the suffix "-1" or "-2" are used when more than one release is made on that day.
I use svn revision numbers...
And you are right, I'm not from marketing
It's for the Zilog Z80 CPU, which the TRS-80 used. Assuming NewDOS/80 was named after said system, it's not an example of an OS given a year instead of version number.
Sorry, my karma just ran over your dogma.
You go to hell. You go to hell, and you die!
Don't forget about these oddballs:
As well as the regular:
And...
Honestly, branches and forks aside (or not), software revisions should be marked with an integer. I vaguely remember that Linus wanted to start doing the same for the kernel. Similarly, for those who like to append the date as a revision number - smarten up and start using the YYYYMMDD format - it's an integer that always sorts in the correct order, at least until the year 9999 + 1.
a single number that goes up one digit everytime there is a code change is called build number.
Those who can, do.
FTA - "Runner up for best version number: 3.11. As in 1993â(TM)s Windows for Workgroups 3,11, one of the best versions of any operating system ever released."
The author instantly lost credibility in my mind. While WfW 3.11 may have been a breakthrough for PC architectures, it's pathetic compared to any other GUI OS from that era. And the only reason it was so great on the PC is because the only other "OS", DOS, was such weak sauce.
But other than that, it was an entertaining article.
Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches Ï. The current version is 3.1415926.
He can get away with that; most of us can't.
likely responded to this, and so shall I.
as part of the scm world -- i like to be true to a real dotted quad notation when referring to build versions. i've never really built code that is deployed to the public world .. only code used on company production servers for public consumption (mostly java based web sites, and middleware)
1.2.3.4 = Major level 1, Minor level 2, Patch 3, Build 4.
Major = major release. no longer compatible with previous versions.
Minor = minor release, still compatible with previous versions (with same Major)
Patch = the number of patch builds required to get to latest production patched code
Build = the daily build number. increments by 1 until dev/qa is complete, and code is released to Staging servers.
build numbers stop, once patching starts. the patching denotes the patch to last known good build.
ie -- dev/qa releases should always be num.num.zero,buildnum. (1.2.0.40)
once released to staging - and if a patch is required -- the rev increments as such for the first patch - 1.2.1.40. second patch 1.2.2.40, and so on.
once in production -- wait until next release.
if code is released to the public, and not running on a company's servers -- always drop the build number. so, if you're delivering 1.2.2.40 binaries to the public, cut it down to 1.2.2 and deliver your rpm/pkg/deb, etc to the world.
if this confuses you, im available for hire at your location. references available upon request. :p
We're like rats, in some experiment! -- George Costanza
Oldest version numbers:
Linear A: Linear A is one of two linear scripts used in ancient Crete before Mycenaean Greek Linear B... Linear A seems to have been used as a complete syllabary around 1900 - 1800 BC,
Linear B: Linear B is a script that was used for writing Mycenaean Greek, an early form of Greek. It predated the Greek alphabet by several centuries (ca. 13th but perhaps as early as late 15th century BC).
Linear C: (Redirected from Linear C [Already the marketers were messing with the version numbers!]) The Cypro-Minoan syllabary (abbreviated CM) is an undeciphered syllabic script used on the island of Cyprus during the Late Bronze Age (ca. 1550-1050 BC).
Beat that!
Can you imagine in 1800 BC how much of a pain the upgrade cycle must have been when everyone had to update their clay tablets?
Or simpler : Mac OS X hello kitty
It isn't a proper version number. Many in between has been skipped, like going from 290 to 330.
Basically, Solaris = SunOS 2.x. (Changing the underlying kernel from BSD to SYSV justifies a new version.) That explains Solaris up to 2.7.
After that, SUN realized they would never have a version 3.0, and they dropped the major version. Hence Solaris 8 and so on.
WWTTD?
Forget version numbers. How did you pick that user name?
At a guess, it has something to do with a common programming exercise in which you try to find the largest possible integer with a square that takes a certain form; in his case, that form must've been 1_2_3_4_5_6_7_7_8_9_.
My guess: 1 nine, 2 nines, 3 nines...
WWTTD?
To whomever moderated that comment down, put down the crack pipe, raise your hands slowly in the air and back away from the keyboard.
k thx bye
That's what your version control revision is for. Some of us would like to be able to tell at a glance whether having 2.3.4 might cause problems when transferring data to a 3.4.5 installation. You try doing that with between version 36978 and 87498.
I agree with you in principle, but it's rarely enforced in the real world. Agreed that 2.3.4 and 3.4.5 are more descriptive than 36978 and 87498.
RBBS was the first PC software to get updated to a teen version number. Wiki says it hit version 17.4 in 1992.
I come here for the love
I just upgraded to Linux version e9e961c9a818a2f24711af493b907a8e40a69efc, I was using 79fbe134832ebb70a49d8802cfeb2401dc35bb38 before.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Some of us would like to be able to tell at a glance whether having 2.3.4 might cause problems when transferring data to a 3.4.5 installation. You try doing that with between version 36978 and 87498.
I like it.
.. Blub falls right in the middle of the abstractness continuum. -- Paul Graham