Refactor versioning documentation and adopt semantic versioning guidelines

doc/stability_release.md

@@ -0,0 +1,28 @@
+# 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. Updates *RELEASE.md*.
+- Once the PR is merged, create a new tag.
+- Initiate the release process by triggering *the binary release processes* in *Actions*.