Open jpl-jengelke opened 6 months ago
Thank you for adding this! I'll review and edit as necessary.
Question out of curiosity: what's the case for maintaining a changelog in source control instead of using a tool like release messages in Github?
Thank you for adding this! I'll review and edit as necessary.
Question out of curiosity: what's the case for maintaining a changelog in source control instead of using a tool like release messages in Github?
Hi Carter,
Thank you for reading through our PR. I'm on a team with @riverma who are working on Lab standards for software, and we also manage this GitHub project (project, not repo) in public GitHub. We are working on presenting unified documentation for all repos in the project, and that is what this PR is attempting to infuse. We hope that the suggested changes can be embraced with/without some modifications to make the standards relevant to this particular software repo.
The case for maintaining a source control changelog centers around how users get the package. Sometimes it is downloaded from release artifacts in the form of a compressed archive (one example) and so users don't always have network access. Moreover, it's a fallback standard that allows a more granular or detailed representation of changes, as necessary. More info is available at https://keepachangelog.com/en/1.1.0/ .
Thanks again,
John Engelke
Hi John,
Thanks for the thoughtful reply! I definitely support the initiative for unified Lab standards and appreciate the rationale behind the changelog.
-Carter
Purpose
Proposed Changes
Automation templates for the following:
MGSS-approved and customized (application-specific) documentation templates:
webdocs
directoryLeveraging SLIM Best Practice Guides: https://nasa-ammos.github.io/slim/docs/category/documentation
https://nasa-ammos.github.io/slim/docs/category/contributions
Issues
Testing