Updates Docs With New Release And Branch System

Previously, we used the semantic versioning system, only tracked
development through the master branch, and had an inconsistent release
cadence.

Now, we are retiring semantic versioning and are switching over to use a
date based system.  Furthermore, we are changing the branch organization
of the repository.  Now, all pull requests will be merged onto the
develop branch.  This branch will track experimental builds (active
development).  The master branch will track verified stable releases,
which will be updated once a month according to our new release cadence.

Changelist:

  - README.md is updated to provide information regarding the new branch
organization
  - docs/Releases.md is updated to have information about our versioning
system and release cadence
  - docs/Contributing.md provides a brief summary on how to get started
with adding code to OpenNetVM

Testing:

  - N/A because all changes are made to docs

README.md

@@ -5,7 +5,7 @@ About
 --
 openNetVM is a high performance NFV platform based on [DPDK][dpdk] and [Docker][docker] containers.  openNetVM is SDN-enabled, allowing the network controller to provide rules that dictate what network functions need to process each packet flow.
 
-openNetVM is an open source version of the NetVM platform described in our [NSDI 2014 paper][nsdi04], released under the [BSD][license] license. 
+openNetVM is an open source version of the NetVM platform described in our [NSDI 2014 paper][nsdi04], released under the [BSD][license] license.  The [develop][dev] branch tracks experimental builds (active development) whereas the [master][mast] branch tracks verified stable releases.  Please read our [releases][rels] document for more information about our releases and release cycle.
 
 You can find information about research projects building on [OpenNetVM][onvm] at the [UCR/GW SDNFV project site][sdnfv]. _Please [let us know](mailto:[email protected]) if you use OpenNetVM in your research so we can add your papers to our list._
 
@@ -37,3 +37,6 @@ NFs can be run inside docker containers, with the NF being automatically or hand
 [examples]: docs/Examples.md
 [nfs]: docs/NF_Dev.md
 [docker-nf]: docs/Docker.md
+[dev]: https://github.com/sdnfv/openNetVM/tree/develop
+[mast]: https://github.com/sdnfv/openNetVM/tree/master
+[rels]: docs/Releases.md

docs/Contributing.md

@@ -0,0 +1,21 @@
+# Contribution Guidelines
+
+To contribute to OpenNetVM, please follow these steps:
+
+  1. Please read our [style guide][style]
+  2. Create your own fork of the OpenNetVM repository
+  3. Add our master repository as an upstream remote:
+      - `git remote add upstream https://github.com/sdnfv/openNetVM`
+  4. Update the `develop` branch before starting your work:
+      - `git pull upstream develop`
+  5. Create a branch off of `develop` for your feature.
+      - We follow the fork/branch workflow where no commits are ever made to `develop` or `master`.  Instead, all development occurs on a separate feature branch.  Please read [this guide][gitflow] on the Git workflow.
+  6. Add your commits
+      - Good commit messages contain both a subject and body.  The subject provides an overview whereas the body answers the _what_ and _why_.  The body is usually followed by a change list that explains the _how_, and the commit ends with a _test plan_ describing how the developer verified their change.  Please read [this guide][commitguide] for more information.
+  7. When you're ready to submit a pull request, rebase against `develop` and clean up any merge conflicts
+      - `git pull --rebase upstream develop`
+  8. Please fill out the pull request template as best as possible and be very detailed/thorough.
+
+[style]: style/styleguide.md
+[gitflow]: https://guides.github.com/introduction/flow/
+[commitguide]: https://chris.beams.io/posts/git-commit/

docs/Releases.md

@@ -1,5 +1,18 @@
 ## Release Notes
 
+#### About:
+##### Release Cycle:
+We track active development through the `develop` branch and verified
+stable releases through the `master` branch.  New releases are created and
+tagged on a monthly cycle.  When we tag a release, we update `master` to
+have the latest stable code.
+
+##### Versioning:
+As of 11/06/2017, we are retiring semantic versioning and will instead
+use a date based versioning system.  Now, a release version can look
+like `17.11` where the "major" number is the year and the "minor" number
+is the month.
+
 #### 8/25/16: Refactoring to improve code organization
 A big set of commits to clean the structure and simplify onvm source code.
 We separated all functions into the main.c of the manager into modules :