From 6f6d29639596389d7f8e83f4259003dbe30d5d4a Mon Sep 17 00:00:00 2001 From: Leonardo Grasso Date: Fri, 4 Feb 2022 12:21:39 +0100 Subject: [PATCH] docs(proposals): versioning schema amendment improvements Signed-off-by: Leonardo Grasso --- ...10524-versioning-and-release-of-the-libs-artifacts.md | 2 ++ proposals/20220203-versioning-schema-amendment.md | 9 +++++++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/proposals/20210524-versioning-and-release-of-the-libs-artifacts.md b/proposals/20210524-versioning-and-release-of-the-libs-artifacts.md index af263cb1e..91c8e3e54 100644 --- a/proposals/20210524-versioning-and-release-of-the-libs-artifacts.md +++ b/proposals/20210524-versioning-and-release-of-the-libs-artifacts.md @@ -40,6 +40,8 @@ This proposal intends to extend on points 10-12 for the libsinsp and libscap pla ### Versioning Scheme +**Superseeded by**: [versioning-schema-amendment proposal](20220203-versioning-schema-amendment.md). + This document proposes to version libscap, libsinsp, and the Falco drivers - all residing in `falcosecurity/libs` - with a single [SemVer 2.0](https://semver.org/spec/v2.0.0.html) string. While libscap and libsinsp - to do not mention the drivers - have different API surfaces, this document proposes to version them as one single machinery to avoid further maintenance burdens and version compatibility matrices (read dependency hell) between all the floating pieces. diff --git a/proposals/20220203-versioning-schema-amendment.md b/proposals/20220203-versioning-schema-amendment.md index e4f2e875e..59a67db55 100644 --- a/proposals/20220203-versioning-schema-amendment.md +++ b/proposals/20220203-versioning-schema-amendment.md @@ -1,6 +1,6 @@ # Versioning schema -Supersedes: [20210524-versioning-and-release-of-the-libs-artifacts.md#versioning-scheme](20210524-versioning-and-release-of-the-libs-artifacts.md#versioning-scheme) +**Supersedes**: [20210524-versioning-and-release-of-the-libs-artifacts.md#versioning-scheme](20210524-versioning-and-release-of-the-libs-artifacts.md#versioning-scheme) ## Summary @@ -53,4 +53,9 @@ For that purpose, this document proposes to use `1.0.0` as the starting point fo - *minor* increases either when `API_VERSION`’s minor or `SCHEMA_VERSION`’s minor number has been increased - *patch* increases either when `API_VERSION`’s patch or `SCHEMA_VERSION`’s patch number has been increased or when any other code changes have been introduced (for example, the support for a new kernel) -Note that no backward-incompatible changes can be introduced without bumping the *major* number of `API_VERSION` or `SCHEMA_VERSION` first. Similar logic applies for the *minor* and *patch* numbers. Since both `API_VERSION` and `SCHEMA_VERSION` follow the SemVer scheme, with this method also, the resulting driver version is guaranteed to respect what the SemVer specification mandates. \ No newline at end of file +Note that no backward-incompatible changes can be introduced without bumping the *major* number of `API_VERSION` or `SCHEMA_VERSION` first. Similar logic applies for the *minor* and *patch* numbers. Since both `API_VERSION` and `SCHEMA_VERSION` follow the SemVer scheme, with this method also, the resulting driver version is guaranteed to respect what the SemVer specification mandates. + +### Other considerations + +Steps described in the +[20210524-versioning-and-release-of-the-libs-artifacts.md#steps](20210524-versioning-and-release-of-the-libs-artifacts.md#steps) section will need to be adapted to accommodate the two different release processes (one for the libs and another for the drivers). \ No newline at end of file