wasm-micro-runtime/doc/stability_release.md

# Semantic Versioning

WAMR has adopted [semantic versioning](https://semver.org/) to replace the former *date versioning system*.  The new version string consists of three parts:

- *major*: Any change that is not compatible with previous versions, affecting either the ABI or APIs, will result in an increase in the major version number. APIs include: wasm_export.h, wasm_c_api.h, sections in AOT files, among others.
- *minor*: This number increases with the addition of new features. This encompasses not only MVP (Minimum Viable Product) or POST-MVP features but also WebAssembly System Interface (WASI) features and WAMR-specific features.
- *patch*: This number is incremented for patches.

## Legacy releases

All previous versions (tags) will retain their current status. There will be no changes to existing release names and links.

# Release Process

WAMR has been deployed across various devices. A frequent release cycle would strain customers' testing resources and add extra deployment work. Two factors can trigger a new WAMR release:

- Community requests, particularly following the integration of significant and new features.
- Security vulnerabilities and critical bug fixes that ensure correctness.

Patch releases will be made only to address security vulnerabilities and critical issues related to default behavior in prior releases.

Once a release decision has been made:

- Create a PR that:
  1. Modifies *build-scripts/version.cmake*.
  2. Executes cmake configuration to update the version.
  3. Updates *RELEASE_NOTES.md*.
- A checklist of the PR includes
  - [ ] *build-scripts/version.cmake*
  - [ ] *core/version.h*
  - [ ] *RELEASE_NOTES.md*
- Once the PR is merged, create a new tag.
- Initiate the release process by triggering *the binary release processes* in *Actions*.
Refactor versioning documentation and adopt semantic versioning guidelines 2024-12-26 00:56:22 +00:00			`# Semantic Versioning`

			`WAMR has adopted [semantic versioning](https://semver.org/) to replace the former date versioning system. The new version string consists of three parts:`

			`- major: Any change that is not compatible with previous versions, affecting either the ABI or APIs, will result in an increase in the major version number. APIs include: wasm_export.h, wasm_c_api.h, sections in AOT files, among others.`
			`- minor: This number increases with the addition of new features. This encompasses not only MVP (Minimum Viable Product) or POST-MVP features but also WebAssembly System Interface (WASI) features and WAMR-specific features.`
			`- patch: This number is incremented for patches.`

			`## Legacy releases`

			`All previous versions (tags) will retain their current status. There will be no changes to existing release names and links.`

			`# Release Process`

			`WAMR has been deployed across various devices. A frequent release cycle would strain customers' testing resources and add extra deployment work. Two factors can trigger a new WAMR release:`

			`- Community requests, particularly following the integration of significant and new features.`
			`- Security vulnerabilities and critical bug fixes that ensure correctness.`

			`Patch releases will be made only to address security vulnerabilities and critical issues related to default behavior in prior releases.`

			`Once a release decision has been made:`

			`- Create a PR that:`
			`1. Modifies build-scripts/version.cmake.`
Add version.h and update versioning documentation for embedded platforms 2025-01-17 04:05:05 +00:00			`2. Executes cmake configuration to update the version.`
			`3. Updates RELEASE_NOTES.md.`
			`- A checklist of the PR includes`
			`- [ ] build-scripts/version.cmake`
			`- [ ] core/version.h`
			`- [ ] RELEASE_NOTES.md`
Refactor versioning documentation and adopt semantic versioning guidelines 2024-12-26 00:56:22 +00:00			`- Once the PR is merged, create a new tag.`
			`- Initiate the release process by triggering the binary release processes in Actions.`