| Message ID | 20230508132444.32525-1-Sai.Sathujoda@toshiba-tsip.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [isar-cip-core] README_cip-core-version-release-policy.md : To define the versioning and release policy | expand |
On 08.05.23 15:24, Sai.Sathujoda@toshiba-tsip.com wrote: > From: Sai <Sai.Sathujoda@toshiba-tsip.com> > > This is the updated patch after making changes based on Jan's comments. This is a change log of the patch and, as such, it should go after the "---" separator. Instead, you need to restore the original commit message here. Please also version your patches, e.g.: [isar-cip-core][PATCH v2] Document versioning and release policy Jan > Signed-off-by: Sai <Sai.Sathujoda@toshiba-tsip.com> > --- > doc/README_cip-core-version-release-policy.md | 31 +++++++++++++++++++ > 1 file changed, 31 insertions(+) > create mode 100644 doc/README_cip-core-version-release-policy.md > > diff --git a/doc/README_cip-core-version-release-policy.md b/doc/README_cip-core-version-release-policy.md > new file mode 100644 > index 0000000..f42e549 > --- /dev/null > +++ b/doc/README_cip-core-version-release-policy.md > @@ -0,0 +1,31 @@ > +# CIP metadata versioning and Release policy > + > +## Table of contents > +1. [Objective](#objective) > +2. [Versioning system](#versioningsystem) > +3. [Release policy](#releasepolicy) > + > +## Objective <a name="objective"></a> > + > +The primary objective is to document the release process, it’s frequency and version changing for isar-cip-core metadata. This metadata can be used by CIP users to create various flavors of images like **security-hardened image, testing image, partition-encrypted image** etc. in architectures like **x86_64, arm64, armhf, riscv64**. > + > +## Versioning system <a name="versioningsystem"></a> > + > +The isar-cip-core metadata follows semantic versioning system i.e **x.y.z** format which is explained below: > + > +1. **z** is incremented only when critical bugs are fixed. > + * For example, if the latest release version is **2.2.5**, then the upcoming release version after fixing some critical bugs will be **2.2.6**. > + > +2. **y** is incremented for each Debian point release or in case of isar-cip-core regular release. When **y** is incremented, **z** is reset to 0. > + * Let us assume that the latest release version is **2.1.1**, then the upcoming regular release version will be **2.2.0**. > + > +3. **x** is incremented when significant changes are done other than **y** and **z**. > + * In cases where recipes are broken fundamentally, or support for an older Debian version is dropped then the value of x is incremented by 1. > + * Let us assume that the latest release version is **1.0.1**. If changes similar to the one mentioned above are done, then the next release will be **2.0**. When **x** is incremented, **y** & **z** are reset to 0. > + > +## Release policy > + > +An approximate time gap of 3 months is taken between consecutive regular releases. During every release, CIP-Core plans to give out recipes (isar-cip-core metadata) using which the user can build the flavor of their choice. > + > +All the releases can be found [here](https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tags). > +
diff --git a/doc/README_cip-core-version-release-policy.md b/doc/README_cip-core-version-release-policy.md new file mode 100644 index 0000000..f42e549 --- /dev/null +++ b/doc/README_cip-core-version-release-policy.md @@ -0,0 +1,31 @@ +# CIP metadata versioning and Release policy + +## Table of contents +1. [Objective](#objective) +2. [Versioning system](#versioningsystem) +3. [Release policy](#releasepolicy) + +## Objective <a name="objective"></a> + +The primary objective is to document the release process, it’s frequency and version changing for isar-cip-core metadata. This metadata can be used by CIP users to create various flavors of images like **security-hardened image, testing image, partition-encrypted image** etc. in architectures like **x86_64, arm64, armhf, riscv64**. + +## Versioning system <a name="versioningsystem"></a> + +The isar-cip-core metadata follows semantic versioning system i.e **x.y.z** format which is explained below: + +1. **z** is incremented only when critical bugs are fixed. + * For example, if the latest release version is **2.2.5**, then the upcoming release version after fixing some critical bugs will be **2.2.6**. + +2. **y** is incremented for each Debian point release or in case of isar-cip-core regular release. When **y** is incremented, **z** is reset to 0. + * Let us assume that the latest release version is **2.1.1**, then the upcoming regular release version will be **2.2.0**. + +3. **x** is incremented when significant changes are done other than **y** and **z**. + * In cases where recipes are broken fundamentally, or support for an older Debian version is dropped then the value of x is incremented by 1. + * Let us assume that the latest release version is **1.0.1**. If changes similar to the one mentioned above are done, then the next release will be **2.0**. When **x** is incremented, **y** & **z** are reset to 0. + +## Release policy + +An approximate time gap of 3 months is taken between consecutive regular releases. During every release, CIP-Core plans to give out recipes (isar-cip-core metadata) using which the user can build the flavor of their choice. + +All the releases can be found [here](https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tags). +