Move pre-release and build sections to last position.

I realized that there is no point in using an exotic tilde when a dot will do
just fine. In addition to being simpler and less weird, this change also means
that you can tag these versions in Git, since ~ is invalid in Git tag names.

semver.md

@@ -1,5 +1,5 @@
-Semantic Versioning 1.0.0
-=========================
+Semantic Versioning 1.0.0-rc.1
+==============================
 
 In the world of software management there exists a dread place called
 "dependency hell." The bigger your system grows and the more packages you
@@ -43,22 +43,15 @@ could be declared in the code itself or exist strictly in documentation.
 However it is done, it should be precise and comprehensive.
 
 1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are
-integers. X is the major version, Y is the minor version, and Z is the patch
-version. Each element MUST increase numerically by increments of one. For
-instance: 1.9.0 -> 1.10.0 -> 1.11.0.
+non-negative integers. X is the major version, Y is the minor version, and Z
+is the patch version. Each element MUST increase numerically by increments of
+one. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
 
 1. When a major version number is incremented, the minor version and patch
 version MUST be reset to zero. When a minor version number is incremented, the
 patch version MUST be reset to zero. For instance: 1.1.3 -> 2.0.0 and 2.1.7 ->
 2.2.0.
 
-1. A pre-release version number MAY be denoted by appending an arbitrary
-string immediately following the patch version and a dash. The string MUST be
-comprised of only alphanumerics plus dash [0-9A-Za-z-]. Pre-release versions
-satisfy but have a lower precedence than the associated normal version.
-Precedence SHOULD be determined by lexicographic ASCII sort order. For
-instance: 1.0.0-alpha1 < 1.0.0-beta1 < 1.0.0-beta2 < 1.0.0-rc1 < 1.0.0.
-
 1. Once a versioned package has been released, the contents of that version
 MUST NOT be modified. Any modifications must be released as a new version.
 
@@ -74,7 +67,8 @@ compatible bug fixes are introduced. A bug fix is defined as an internal
 change that fixes incorrect behavior.
 
 1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
-compatible functionality is introduced to the public API. It MAY be
+compatible functionality is introduced to the public API. It MUST be
+incremented if any public API functionality is marked as deprecated. It MAY be
 incremented if substantial new functionality or improvements are introduced
 within the private code. It MAY include patch level changes. Patch version
 MUST be reset to 0 when minor version is incremented.
@@ -84,22 +78,29 @@ incompatible changes are introduced to the public API. It MAY include minor
 and patch level changes. Patch and minor version MUST be reset to 0 when major
 version is incremented.
 
+1. A pre-release version MAY be denoted by appending a dash and a series of
+dot separated identifiers immediately following the patch version. Identifiers
+MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-].
+Pre-release versions satisfy but have a lower precedence than the associated
+normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7,
+1.0.0-x.7.z.92.
 
-Tagging Specification (SemVerTag)
----------------------------------
-
-This sub-specification SHOULD be used if you use a version control system
-(Git, Mercurial, SVN, etc) to store your code. Using this system allows
-automated tools to inspect your package and determine SemVer compliance and
-released versions.
-
-1. When tagging releases in a version control system, the tag for a version
-MUST be "vX.Y.Z" e.g. "v3.1.0".
-
-1. The first revision that introduces SemVer compliance SHOULD be tagged
-"semver". This allows pre-existing projects to assume compliance at any
-arbitrary point and for automated tools to discover this fact.
+1. A build version MAY be denoted by appending a plus sign and a series of dot
+separated identifiers immediately following the patch version or pre-release
+version. Identifiers MUST be comprised of only ASCII alphanumerics and dash
+[0-9A-Za-z-]. Build versions satisfy and have a higher precedence than the
+associated normal version. Examples: 1.0.0+build.1, 1.3.7+build.11.e0f985a.
 
+1. Precedence MUST be calculated by separating the version into major, minor,
+patch, pre-release, and build identifiers in that order. Major, minor, and
+patch versions are always compared numerically. Pre-release and build version
+precedence MUST be determined by comparing each dot separated identifier as
+follows: identifiers consisting of only digits are compared numerically and
+identifiers with letters or dashes are compared lexically in ASCII sort order.
+Numeric identifiers always have lower precedence than non-numeric identifiers.
+Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 <
+1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build <
+1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.
 
 Why Use Semantic Versioning?
 ----------------------------
@@ -202,6 +203,10 @@ strictly be considered a patch release. Remember, Semantic Versioning is all
 about conveying meaning by how the version number changes. If these changes
 are important to your users, use the version number to inform them.
 
+### How should I handle deprecating functionality?
+
+Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
+
 
 About
 -----