How do you handle versions of the software you build?

There are many ways to handle this issue.  It seems so simple, but there are subtleties that generally seem to cause problems sooner or later.  A naive way to handle the issue is to give the software the version you want it to have when you release, say "1.0", and then keep writing, building, and testing until you think it's ready for release.  But then how do you tell which build is the final one?  Sooner or later, this will bite you and you'll grab the wrong version.  "Which version 1.0 should we ship?"

How do you name your release versions?  You can call them "1" "2" and "3" if you want.  It's more common to have major and minor release versions, e.g., "1.0" "1.1" 1.2" "2.0" "2.1", to differentiate minor enhancements from large changes.  Then there are various strategies for marking bug fix releases or other changes to the build:
 * Patch level: "1.0" "1.0.1" "1.1" "1.2" "1.2.1" "1.2.2"... with the third number indicating subsequent release of a version that changes it, but doesn't add significant functionality.
 * Build number: "1.0.124" "1.1.303"...  with the third number indicating a count of builds (on the official build machine) made up to that point on that release.  This number can be automatically incremented, giving every build a unique ID, though the released builds no longer have sequential numbers.
 * Mnemonic identifier: "1.0dev" for a development build, "1.0.rc1" for release candidate 1, "1.0" for the release, and "1.0p1" for the first patch.

I don't have a "single best practice" to recommend, but I do have a list of recommendations to keep in mind.
 * An official version number should be available while the software is running.  That number should identify it uniquely among the set of released builds.
 * Some unique identifier for every build that can be examined without running the software.  This could be the machine name and timestamp of the build, for example.  That identifier can be used to distinguish between two builds when they have become confused.
 * A clear, simple, and easy process for updating the version/build identifiers.  Bonus points if this process is automatic.  If it's not clear, different people will do different things.  If it's not simple, mistakes will be made.  If it's not easy, shortcuts will be taken.

Let me know your favorite practices.