They will use four, to include a build number, but I don't think that I will. This is used specifically in the auto-update feature, so the Bloglines Toolkit, at least, needed to support it. And since we all know that I'm so anal about those things, I couldn't have the toolkit supporting it while the other software didn't.
So I made sure that everything had a nice, pretty, five-digit (three numbers, two dots) version number. 1.0 became 1.0.0 and so on. Life was good.
Well, then I started updating things. And 1.0.0 became 1.0.1 in some instances, 1.1.0 in others and perhaps even 2.0.0 in still more cases. So I've decided I need to rein this back in a bit. Starting with the release of MT-Approval 1.0.0 yesterday, I will be attempting to stay within the guidelines I'm setting forth.
The major version number (that's the first digit) will only change when significant extra functionality is added to a single release or such a number of smaller functions has been added since the last major release, the product is now vastly different. This latter option is really very subjective, but I'll try to be good with it.
The minor version number (the third digit, the second number) will change upon releasing new features that did not exist in the product before. For instance, the recent addition of a transfer function from Movable Type notifications to MT-Notifier would signify a change in the minor version, since it was in reality a very small change.
That last number, the release, is going to be the one that moves the most often, and it will be incremented at any time that a bug fix is released (same code, but it works now) or minor additional functionality is added to the code. An example of this is the update to MT-Notifier to fix the purge problem.
I'll try to stick to these guidelines as much as possible, so that you know if you're getting a bug fix, extra features, or a whole bunch of stuff.