Release/maintainence workflow and repository branch structure

[eteq]

This is related to #6 but different enough to be worth a new issue, I'd say.

The idea here (which @stscicrawford and I just talked about) would be to lay out a few different release/repo branch strategies, organized so that there are "upgrade" paths between them. The three I think make the most sense are:

1. All work happens on master, when a new version is ready, release and never support anything again. Bug fixes always just go into master. (the "scientist" use case?)
2. All work happens on master, but there is a maintenance branch that is only the most recent release. Hotfixes come out of that branch as new tags, get backported manually, with milestones (or a "needs-backporting" label?) on github used to identify which should be backported. (I think this is basically the workflow in https://innerspace.stsci.edu/display/~dencheva/Github+and+Release+Workflow )
3. The astropy workflow, where there is a latest major branch and some number (for astropy just one) of older versions to maintain. See the Astropy docs like http://docs.astropy.org/en/stable/development/releasing.html for more on this

All come with the option (probably recommended for all except maybe 1) of a stable branch that points to the latest release.

[eteq]

Oh and the main interconnection with #6 is that the developer needs to know if they are responsible for backporting, vs the release manager. That should be stated explicitly somewhere - probably in both the release and the developer workflow discussion (this & #6), but with one linking to the other for details.

[stscicrawford]

I've assigned @nden to write up a first draft. For a first draft, it should summarizes the JWST release work flow and the git work flow taught in the ST git classes