Documentation Changes for Git Usage, Branching Model, and Release Management

[robertbartel]

Modifying and expanding documentation related to release management and new Git branching model.

Note the big caveat: this release process documented in this change deviates somewhat from the discussed branching model (or at least from things implied in those discussions). This was due to ngen-cal being composed, essentially exclusively, of several separate, independently-versioned Python packages. This is in contrast to something like DMOD, which similarly has several nested, individually-versioned packages, but also contains many other things without an independent versioning mechanism, such that a distinct version scheme for the repo as a whole is justified and necessary.

Regardless, for ngen-cal, instead of one version tagging scheme for the whole repo, package-specific tags are expected to be applied as appropriate any time the release process is executed (see RELEASE_MANAGEMENT.md for details). Both the strategy itself and the documented explanation deserve careful review and may require further discussion.

Additions

• New RELEASE_MANAGEMENT.md doc with details on release process
• New GIT_USAGE.md with info on Git usage and branching model

Changes

• Updated CONTRIBUTING.md with some additional info and to be consistent with other repos
• Move some details present in CONTRIBUTING.md to GIT_USAGE.md

Testing

1. None; doc updates only

Todos

• The specifics for "testing and quality pre-release tasks" during the release process need to be decided upon and documented.
• The exact process for peer reviewing changes made to release branches (e.g., bug fixes) during the release process needs to be decided upon and documented.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist (automated report can be put here)

Target Environment support

• Linux

[christophertubbs]

B-e-a-utiful. Good job.