tagging format inconsistent with RTD

[laroque]

Problem

RTD has an automatic label for what it considers to be the "stable" version of a package. This is based on some logical sort/parsing of tags. Our convention of wpX1.Y1.Z1_pythonX2.Y2.Z2 is not recognized and the build always goes for the existing v3.1.0 rather than wp2.1.1_python3.6.0.

Suggestions

We have several options (note that here [X,Y,Z] are the [Major,Minor,Patch] version numbers, and 1 indicates values for the wire-protocol, while 2 denotes values for this repo):

1. (currently implemented) Disable "stable" and enable building HEAD of the master branch and use that as the default rather than stable. Advantage: is already configured and working. Disadvantage: is not parallel to the rest of our repos which are able to use stable.
2. Change the convention to vX2.Y2.Z2_wpX1.Y1.Z1 (may want a - rather than a _ between the two. Advantage: would likely result in correct "stable" builds (requires testing), making things more parallel; retains both package and WP version information (if this is the correct place for that). Disadvantage: requires testing to ensure desired behavior achieved; assumes we still want WP version in tags.
3. Change the convention to vX2.Y2.Z2. Advantage: Would work as expected on RTD; would fully parallel our other repos. Disadvantage: Does not have WP information in the version string (again, do we want that?).

Notes

• The current convention is based on the old Repo organization where multiple languages were coexisting. It is no longer necessary to specify that a version is for python, since that is the only language present in the repo.
• The sender_info version info is derived from the verstr in the setup.py file, which is populated based on a call to git describe (of this repo, not of some repo for which dripline-python is a dependency).
• Our other dripline-<language repos all use convention 3.

[wcpettus]

I like convention 3

• for tags v3.1.0 and earlier, we already used this
  • we've only bumped wp twice in this time, compared to 16 bumps of dripline-python version
• our current convention makes tagging our python environment significantly longer
• if we want the wp version specified to put into sender_info (https://github.com/project8/dripline/issues/174), we bump infrequently enough that it can be hardcoded
• at a glance, the current convention looks like we are selecting a python version we are building against (this will be obviously false when we bump to dripline-python v4.0.0), which can be confusing for python2 and python3 versions
• if desired, we can add a versions tracker (like https://github.com/project8/dripline/blob/master/Version.rst) to mark which dripline-python versions adopt a new WP