- From the perspective of users who use the framework, always update CHANGELOG.md when there are changes to the package
- Basically, an update is required when there are changes to non-private classes or methods under src/
- At this time, note that if the implementation involves a breaking change, it must be handled by updating the minor version or major version in SemVer
- However, changes made to fix internal defects (bug fixes) may allow a patch version update if they are breaking changes with low impact
Important Formatting and Content Rules
When updating CHANGELOG.md for changes, follow the format below.
- The format is based on Keep a Changelog based on
- The CHANGELOG describes all changes visible from the user's perspective
- Rather than writing the implemented details, concisely describe what feature additions, changes, or fixes occurred from the perspective of the people who use the service (users)
- Write what changes occurred in the outer part that serves as the so-called interface when users view this framework
- Write not what changes occurred in this framework, but what impact they have when users use it
- PR and Issue numbers should be written in link format such as
[#123](github.com/your-repo/issues/123)describe in link format as - Use systems, code, or classes as the subject
- Describe changes, additions, etc. concisely
- For bug fixes, describe what events or problems were occurring
- If there are alternatives, describe them
- Write class names using the FQCN even if somewhat verbose