Update version numbering and clarify notes updates

pip resolves x.y.z-rc0 and x.y.z-pre0 to the same version number which caused
problems for people installing pants with pip. The dev suffix does not conflict
with rc in PEP440.  The version numbering has been verified to not cause
conflicts with a small test package and the following:

In [1]: from pip._vendor.packaging import version

In [2]: version.parse('1.1.0dev0')
Out[2]: <Version('1.1.0.dev0')>

In [3]: version.parse('1.1.0rc0')
Out[3]: <Version('1.1.0rc0')>

In [4]: version.parse('1.1.0')
Out[4]: <Version('1.1.0’)>

* Change pre to dev to avoid naming issues with PEP.
* Clarify notes that need to be updated on cutting a new stable branch.

Testing Done:
CI pending: https://travis-ci.org/pantsbuild/pants/builds/144253603

Bugs closed: 3658

Reviewed at https://rbcommons.com/s/twitter/r/4069/

src/docs/release.md

@@ -77,10 +77,13 @@ and CONTRIBUTORS management are not. Changelog edits and CONTRIBUTOR updates alw
 occur in master, while version changes generally only occur in the relevant release branch.
 
 1. In your release branch: Edit the version number in `src/python/pants/version.py`
-2. In master and your release branch: Add an entry for the release to the changelog for the branch
-under `src/python/pants/notes/*.rst`. You can run `./build-support/bin/release-changelog-helper.sh`
-to get a head-start creating the relevant changelog entries.
-3. In master: Bring the CONTRIBUTORS roster in
+2. When a `stable` branch is cut update `src/python/pants/notes/*.rst` and
+  `src/python/pants/notes/master.rst` on the master branch to reflect changes captured in the stable
+  branch.  For `dev` releases only update master.rst.  Future `stable` changes will be cherry-picked
+  to the stable branch so master and stable will diverge, only requiring the branch specific notes
+  to be updated.  You can run `./build-support/bin/release-changelog-helper.sh`
+  to get a head-start creating the relevant changelog entries.
+3. In master and the release branch if needed: Bring the CONTRIBUTORS roster in
 [CONTRIBUTORS.md](https://github.com/pantsbuild/pants/tree/master/CONTRIBUTORS.md)
 up to date by running `build-support/bin/contributors.sh`.
 

src/docs/release_strategy.md

@@ -11,12 +11,12 @@ The release manager is responsible for:
 
 * Creating `stable` branches
 * Creating and gathering feedback on release candidates
-* Cutting `pre` and `stable` releases
+* Cutting `dev` and `stable` releases
 
 These release types and responsibilities are described below.
 
 ## Release Cadence
-The release manager for a particular week decides whether to cut `stable` or `pre` releases (or
+The release manager for a particular week decides whether to cut `stable` or `dev` releases (or
 both!) based on the following criteria:
 
 1. Decide whether to create a _new_ `stable` branch:
@@ -26,20 +26,20 @@ since the previous `stable` branch was created, and decide whether the changes j
 `stable` branch (this is intentionally left open for discussion). If a new `stable` branch is
 justified, it will be either a `major` or `minor` branch (described below).
     * If a new `stable` branch is _not_ created (because of insufficient time/change to justify the
-stable vetting process), the release manager must cut a `pre` release from master instead.
-2. In addition to any `pre` release or newly-created `stable` branches, the release manager should
+stable vetting process), the release manager must cut a `dev` release from master instead.
+2. In addition to any `dev` release or newly-created `stable` branches, the release manager should
 determine whether any existing `stable` branches need new release candidates by inspecting the
 [Pants Backport Proposals](https://docs.google.com/spreadsheets/d/12rsaVVhmSXrMVlZV6PUu5uzsKNNcceP9Lpf7rpju_IE/edit#gid=0)
 sheet. If there are requests "sufficient" to justify `patch` releases for existing `stable` branches, the
 release manager should cut release candidates for those branches.
 
-In other words, for a given week: _one of either_ a `pre` release or a new `stable` branch are
+In other words, for a given week: _one of either_ a `dev` release or a new `stable` branch are
 created, and additionally, `patch` releases for existing `stable` branches _might_ be created.
 
 ## Release Types
 
-### `pre` releases
-`pre` releases are releases that occur directly from master, without the additional vetting that
+### `dev` releases
+`dev` releases are releases that occur directly from master, without the additional vetting that
 is applied to `stable` releases. They help to ensure a steady release cadence from master by filling
 in the gaps between the (generally more time consuming) `stable` releases.
 
@@ -69,28 +69,28 @@ only include commits from the Pants Backport Proposals that are deemed to be
 Leading up to a `stable` release, development work should be done on a branch named with the
 following format: `n.n.x` where n.n are the `major`/`minor` version numbers and "`x`" is a literal
 character placeholder for the `patch` version. Release candidates of an upcoming `stable` release
-are suffixed with `-rcN`. For instance: "the `1.1.x` `stable` branch",
-"the `1.1.1-rc0` release candidate", and "the `1.1.1` `stable` release".
+are suffixed with `rcN`. For instance: "the `1.1.x` `stable` branch",
+"the `1.1.1rc0` release candidate", and "the `1.1.1` `stable` release".
 
 
-### `pre` naming
-`pre` releases occur between `stable` branches, and are differentiated by a `-preN` suffix. The pattern
-to follow is `N.N.0-preN`, where `N.N` are the _next_ `major`/`minor` branch that will be created
-and N is the next sequential number starting from `0`. For instance: "the `1.1.0-pre0` `pre` release".
+### `dev` naming
+`dev` releases occur between `stable` branches, and are differentiated by a `devN` suffix. The pattern
+to follow is `N.N.0devN`, where `N.N` are the _next_ `major`/`minor` branch that will be created
+and N is the next sequential number starting from `0`. For instance: "the `1.1.0dev0` `dev` release".
 
 ## Examples
 
 * Leading up to the release of `2.0.0` the release manager would create a `stable` branch with
-the literal name "`2.0.x`". They would cut release candidates named `2.0.0-rc0` (and so on), and
+the literal name "`2.0.x`". They would cut release candidates named `2.0.0rc0` (and so on), and
 afterwards, they'd finalize the `2.0.0` release in that `2.0.x` branch by tagging the
 commit with the release version: `v2.0.0`.
 
 * If a release manager had a bugfix from master that they needed to backport to the `1.1.x` `stable`
 branch, they would cherry-pick the commit to the `1.1.x` branch, run a series of release candidates
-(ie, `1.1.1-rc0`, etc), and finally tag the validated commit with a new patch version (ie `v1.1.1`).
+(ie, `1.1.1rc0`, etc), and finally tag the validated commit with a new patch version (ie `v1.1.1`).
 
-* If `pre` releases were required after having created the `1.0.x` branch, but before having created
-the `1.1.x` branch, then they would start with `1.1.0-pre0`, and continue weekly to `1.1.0-preN`
+* If `dev` releases were required after having created the `1.0.x` branch, but before having created
+the `1.1.x` branch, then they would start with `1.1.0dev0`, and continue weekly to `1.1.0devN`
 until the `1.1.x` branch had been created.
 
 ## `stable` Release Candidates