Refactor versioning documentation and adopt semantic versioning guidelines

build-scripts/version.cmake

@@ -1,7 +1,10 @@
 # Copyright (C) 2019 Intel Corporation.  All rights reserved.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
-# BE AWARE: This file depends on ${WAMR_ROOT_DIR}
+if(NOT WAMR_ROOT_DIR)
+  # if from wamr-compiler
+  set(WAMR_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/..)
+endif()
 
 set(WAMR_VERSION_MAJOR 2)
 set(WAMR_VERSION_MINOR 2)

doc/semantic_version.md

@@ -1,21 +0,0 @@
-# WAMR uses semantic versioning
-
-WAMR uses the _semantic versioning_ to replace the current _date versioning_ system.
-
-There are three parts in the new version string:
-
-- _major_. Any incompatible modification, on both ABI and APIs, will lead an increment
-  in the value of _major_. APIs includes: `wasm_export.h`, `wasm_c_api.h`,
-  _sections in AOT files_, and so on.
-- _minor_. It represents new features. It includes not just MVP or POST-MVP features
-  but also WASI features and WAMR private ones.
-- _patch_. It represents patches.
-
-## Legacy versions
-
-All legacy versions(tags) will keep their current status. No existing release names
-and links will be changed.
-
-## Reference
-
-- [Semantic Versioning 2.0.0](https://semver.org/)

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*.

wamr-compiler/CMakeLists.txt

@@ -285,6 +285,7 @@ include (${IWASM_DIR}/common/gc/iwasm_gc.cmake)
 include (${IWASM_DIR}/interpreter/iwasm_interp.cmake)
 include (${IWASM_DIR}/aot/iwasm_aot.cmake)
 include (${IWASM_DIR}/compilation/iwasm_compl.cmake)
+include (${PROJECT_SOURCE_DIR}/../build-scripts/version.cmake)
 
 if (WAMR_BUILD_LIBC_BUILTIN EQUAL 1)
   include (${IWASM_DIR}/libraries/libc-builtin/libc_builtin.cmake)