Methinks they don't understand the concept of "Major release.minor release"
Look at the memory changes from 4->8, they're putting in updates little by little. The train station model of development fits web browsers much better than prolonged giant version leaps that change almost everything.
And try to tell me the version doesn't matter when there's a regression or otherwise something broken on a newer rev that works fine on an older one.
I don't know where this recent trend of "version numbers are evil" came from, but it's entirely silly.
On the dev side, you might refer to a particular code snapshot with a "version number" that might as well be 3.2 or r304 or "2011-08-3 12:03:47" or d1b119d8f117b16fcfa58b2be60df87a6c45ac58. Considering the nightmares caused by conservative IT groups enforcing version X of software Y for years, eliminating version numbers from the public for something as critical as a browser seems like a good move to me on security alone. For other things the formal major.minor.release-revision can still make sense. Personally I miss the "even minor version represents stable, odd unstable" pattern that's increasingly fallen out of use.
Web apps and installed programs are completely different animals.
Among other things, that has improved the quality of the browser, since features don't have to rush to meet the release deadline when they can just wait for the next one right around the corner.
I've always been a fan of this definition: A minor release contains bugs fixes and minor feature changes (For example, 1.0 to 1.1). Major releases include major functionality and feature enhancements (e.g. 1.x to 2.0).
The problem comes in that they're releasing minor bugfixes and patches as major releases, for no other reason than to compete on the numbers system.
I don't think the answer is "abolish the numbers", I think the answer is "be honest".
get over it. it doesn't make any difference to you what number they want to call it.