Protocol for version releases

[dlebauer]

I noticed that the README said the repository would be reorganized by the end of November, but could not find any clear information in the commit history, emails, or issues about the status of this effort. So I submitted #921 to update the target date. Here I suggest a standardized protocol for grouping issues into milestones and releasing versions that I believe would help to keep the issue list organized ... It would also support the teaching mission and serve as an example that can be adapted for other software projects.

For an example of this implementation, see the shameless plug for our software, PEcAn, in which each release is associated with a git tag, release notes, and doi (via zenodo hook). These can then be tweeted, emailed, and otherwise announced. Here is an adapted protocol based on one of ours.

• Planning Phase
  • Create a pre-release including a list of key expected features to be implemented during the sprint.
  • This pre-release is a road-map to the individual features to be implemented
  • Create a milestone, and issues associated with the release
  • Merge pull requests into the master branch as necessary.
• Upon Milestone Completion
  • Merge any remaining pull requests into master.
  • Test
  • Deploy
  • Revise pre-release notes based on actual features implemented
  • Tag the version to be released
  • Copy-paste doi badge markdown code from Zenodo
  • Announce release (copy-paste from Release notes) on Twitter and mailing lists

[gvwilson]

We now have a protocol for lesson releases.