Fermitools Release Tagging/Versioning

When we decide to generate a build for release Joe Asercion will update the version string of Fermitools to to reflect what changes have been made.  This change will occur in the Fermitools-conda meta.yaml file, which updates the metadata of the binary which will be uploaded to the Fermi Anaconda Cloud channel for distribution, and will be used in the tagging of the Fermitools constituent package repositories in the Fermi-Lat github.com organization using repoman's mass tagging ability.  Release tags will be of the form: Fermitools-x.x.x

Our latest (and first!) public release starts the Fermitools at version Fermitools-1.0.0.  The FSSC would like create a formal definition of how we iterate this version number.  Right now, we use the current convention of:

v.r.p->version.revision.patch->Major Update.Minor Update.Patch

But we were unable to find any sort of documentation that defines what constitutes a Major Update, a Minor Update, or a patch.  I propose the following:

Major Update: Iteration implies large functionality changes, new tools introduced, api changes, or other major change

Minor Update: Iteration implies new data files/models, updates to specific individual tools, technical changes that obviously change the user interface (to a smaller extent than a major change, etc.)

Patch: Iteration implies bug fixes/patches to technical problems brought to the attention of the developers