No, big number changes mean that six weeks have passed. That's all. The scale of the change doesn't affect the number at all.

Which is kind of the problem. The standard way of doing it is major release.minor release.build

If it wasn't for this whole "Let's start bumping our version number to match Chrome's insanity" thing, we'd still be on Firefox 9 something.

It has nothing to do with Chrome, and everything to do with 6-weekly updates.

Think of it: You have no way to know, going in, whether the changes in any given update will be big enough to "warrant" a major version change. Worse, what if those features aren't stable enough to release and are turned off? It's very difficult to go from version N to version (N-1).

For these reasons (and others), it's a lot easier for us to unconditionally bump the major version every 6 weeks.

Source: I am a Firefox developer and a Mozilla employee.

That's his problem: The numbers in versions have traditionally (and more usefully) been used to denote levels of feature change and bugfix. A time-based arbitrary version number is pointless; it'd make more sense to use a timestamp for a version number if they're going to do it that way.

The big number change means we're breaking binary compatibility which does happen every 6 weeks now. The version isn't meaningful to most users these days but it does matter to developers who must adapt and adjust as Firefox progresses.

So what?