Functionally works, but I want to align on how to move through this change management.
Originally posted by @bmuenzenmeyer in #911 (review)
We need to define a release system that works for us. Personally, I think:
doc-kit 1.0 is considered a beta release. Minor versions may contain breaking changes, but patch versions will not.
doc-kit 2.0 is considered a stable release, and follows semver.
"Breaking changes" define changes that break the input API, and would prevent consumers from upgrading doc-kit, they do not include breaking change to the output, e.g. UI or color changes. Those are minors.
Functionally works, but I want to align on how to move through this change management.
Originally posted by @bmuenzenmeyer in #911 (review)
We need to define a release system that works for us. Personally, I think:
doc-kit 1.0 is considered a beta release. Minor versions may contain breaking changes, but patch versions will not.
doc-kit 2.0 is considered a stable release, and follows semver.
"Breaking changes" define changes that break the input API, and would prevent consumers from upgrading doc-kit, they do not include breaking change to the output, e.g. UI or color changes. Those are minors.