release-notelisted

# Semantic Versioning (SemVer) Release Notes Guideline This document defines the standard steps and rules for writing Release Notes for the project, based on [Semantic Versioning 2.0.0 (semver.org)](https://semver.org/). ## 1. Core Rules of SemVer (X.Y.Z) Every release version must follow the **MAJOR.MINOR.PATCH** format (e.g., `1.4.2`). You must increment the respective element based on the scope of changes: * **MAJOR (X):** Increment when you make **incompatible API changes** (Breaking changes). When MAJOR is incremented, MINOR and PATCH must be reset to `0` (e.g., `1.4.2` $\rightarrow$ `2.0.0`). * **MINOR (Y):** Increment when you **add functionality** in a backward-compatible manner. When MINOR is incremented, PATCH must be reset to `0` (e.g., `1.4.2` $\rightarrow$ `1.5.0`). * **PATCH (Z):** Increment when you make backward-compatible **bug fixes** without adding new features or breaking existing APIs (e.g., `1.4.2` $\rightarrow$ `1.4.3`). > **Note:** Major version zero (`0.x.x`) is for initial development. Anything MAY change at any time. The public API should not be considered stable. ### 1.1. Additional Labels (Pre-release & Build Metadata) SemVer allows appending labels to define the lifecycle of a release more precisely: * **Pre-release:** Denoted by a hyphen `-` immediately following the PATCH version. These versions have a lower precedence than the associated normal version and are used for drafts or testing phases. * *Examples:* `1.0.0-alpha`,