CSE Release Procedures

• Retain current 0.xxx version number sequence for now. Probably adopt semantic versioning after 1.0 release.
• Each released version distributed via SVN or otherwise will have a unique version number and will have a corresponding GitHub release.
• A release can be built based on any GitHub branch, but it must be tagged and a full release assembled in GitHub.
• Each GitHub release includes the corresponding cse.exe (added to the release by hand via the github UI).
• Values and notes in csevrsn.h retain the primary version number. By-hand communication will be used to coordinate. Generally, this means the master branch csevrsn.h must be kept up-to-date, independent of the merge state of other files among branches.
• To finalize a version --
  • Set CSEVRSN_MINOR (if needed) and history comment in csevrsn.h. Communicate with people working on other branches if needed to ensure uniqueness.
  • Build / test / tag / assemble release. Commit cse.exe to SVN (if public) and/or notify team members that the release is available on GitHub.
  • If test case reference files are changed, the updated reference files should be pushed with the final version number before the release is assembled (in other words, reference files are part of the release).
  • When the dust has fully settled, increment CSEVRSN_MINOR and merge/push csevrsn.h to GitHub master.