Ask 5 developers and you'll probably get 6 different suggestions for version numbering.
Whatever versioning number system you choose, you should make sure it follows certain guidelines. Most package management systems like to be able to figure out which is the latest version, so you should make sure your version number system always increases, with the first number having highest precedence, the second the second highest, etc. For instance, if you're on release 3 now, you shouldn't regress to release 1.4 if you decide to go with an X.Y system, you should at least start on 3.1 or 4.0. Most package management systems have some concept of an epoch to fix up cases like this in which a version number regresses, but you shouldn't rely on that.
In general, your version number should consist of dotted numbers, each increasing in numeric order (thus, 1, 2, 3, ..., 9, 10, 11..., not lexicographic order which would be sorted 1, 10, 11, 2, 3, ...).
Some people like to use a major.minor.patch system, in which the major number increments for backwards incompatible changes or major new features, the minor number increments for backwards-compatible changes or minor new features, and the patch changes only for backwards-compatible bugfixes which don't introduce any new functionality.
Others like to use a system like Ubuntu, with year.month or year.release (possibly with a third number as well for patches or bugfixes, or year.month.day). This can help avoid having to decide what constitutes a "major" feature, and can give people a somewhat more memorable number than an arbitrary "7" or "23". This has the disadvantage of not letting your users know when you make backwards-incompatible changes, though depending on what you're doing, that may be less relevant (if you always maintain backwards compatibility, or if you're numbering something like a Linux distribution which contains so many parts, some of which may be backwards compatible and some of which may not, that guaranteeing backwards compatibility between versions doesn't really make sense).
If you feel like you can commit to a strong notion of backwards compatibility, I'd recommend using a major.minor.patch system following the guidelines given in Semantic Versioning. In these guidelines, you increment the major version for backwards-incompatible changes. You increment the minor version for backwards compatible changes that may still add new functionality (so someone might depend on version greater than 2.3.0, as that's the version that a new feature was added, but less than 3.0.0, as that may have incompatible changes). You increment that patch level only for bugfixes. If you're on release 3 right now, I'd start your next release at 4.0.0, and then follow this model from now on.
If you don't feel like doing the work to ensure compatibility and determine what is and isn't backwards compatible, then just go with year.month, year.month.version or year.version, where the version increments by 1 for each release within that month or year (depending on your frequency of releases). Your next version would thus be something like 2010.1, 2010.8.1, or 2010.8, depending on the exact form (or you could just go with 10.1, 10.8.1, etc).
(Hmm. I'm just one developer, and I think I've given you at least 6 choices by now. Oh well, hope one of them works for you)