Shop Project - Documentation
Changelog Guidelines
To ensure the traceability of changes for the entire team, this project follows the principles of "Keep a Changelog" and uses Semantic Versioning (SemVer).
General Principles
Written for humans: Entries must be easy to understand. Raw technical commits (e.g., "fix typo" or "merge branch") do not belong in the changelog.
Chronological order: New releases and modifications always appear at the top.
Date format: Every version must include its release date in ISO format (`YYYY-MM-DD`).
The 6 Standard Categories
Changes within a version are strictly divided into the following groups:
| Category (Key) | Meaning & Application |
|---|---|
| Added | For completely new features and functions (e.g., new registration). |
| Changed | For changes to existing functions (e.g., router logic optimized). |
| Deprecated | Announcements for components that will be removed in future versions. |
| Removed | Features or old modules that have been completely deleted in this version. |
| Fixed | For any fixed bug, code error, or unexpected system behavior. |
| Security | Critical updates, closing security vulnerabilities (e.g., SQL injections). |
Semantic Versioning (SemVer)
Version numbers follow the format `MAJOR.MINOR.PATCH` (e.g., `1.2.3`):
MAJOR (`1`.x.x): Incompatible changes to the core (Breaking Changes). Views or APIs must be refactored.
MINOR (x.`2`.x): Backward-compatible new features or major milestones (e.g., your stages from 0.1 to 0.16).
PATCH (x.x.`3`): Backward-compatible pure bug fixes and hotfixes.