| Message ID | 20230505175629.4635-1-Sai.Sathujoda@toshiba-tsip.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [isar-cip-core] README_cip-core-version-release-policy.md : To define the versioning and release policy | expand |
On 05.05.23 19:56, Sai.Sathujoda@toshiba-tsip.com wrote: > From: Sai <Sai.Sathujoda@toshiba-tsip.com> > > This document explains the versioning style used for isar-cip-core > metadata releases, frequency of the releases and their policies. > > Signed-off-by: Sai <Sai.Sathujoda@toshiba-tsip.com> > --- > doc/README_cip-core-version-release-policy.md | 42 +++++++++++++++++++ > 1 file changed, 42 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..14cd839 > --- /dev/null > +++ b/doc/README_cip-core-version-release-policy.md > @@ -0,0 +1,42 @@ > +# CIP metadata versioning and Release policy > + > +## Table of contents > +1. [Objective](#objective) > +2. [Versioning system](#versioningsystem) > +3. [Release policy](#releasepolicy) > + > + ***** > +<div style='page-break-after: always'></div> > + > +## Revision History > +| Revision No | Date | Change description | Author | Reviewed by | > +|-------------|------------|---------------------------------------------------------------|--------------|-------------------------------------------| > +| 001 | 2023-05-04 | Draft document for CIP versioning and release policy | Sai Ashrith | | > + Err, this is not a legacy Word document. We have git as versioning control system where we can easily leave all this information (and more) in the commit message. So, please drop. > +**** > +<div style='page-break-after: always'></div> > + > +## 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 image, Maybe "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. > + * Let us assume that the latest release version is **2.1.1**, then the upcoming regular release version will be **2.2.1**. Nope, we will also reset z to 0 when incrementing y. That's standard. > + > +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. The images built after locking the package feeds to a specific snapshot date will be bit-identically reproducible. We are not yet bit-identically reproducible, but this is clearly a goal. So, we better not over-promise here. > + > +All the releases can be found [here](https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tags). > + Thanks a lot for picking up this task and writing the doc! Jan
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..14cd839 --- /dev/null +++ b/doc/README_cip-core-version-release-policy.md @@ -0,0 +1,42 @@ +# CIP metadata versioning and Release policy + +## Table of contents +1. [Objective](#objective) +2. [Versioning system](#versioningsystem) +3. [Release policy](#releasepolicy) + + ***** +<div style='page-break-after: always'></div> + +## Revision History +| Revision No | Date | Change description | Author | Reviewed by | +|-------------|------------|---------------------------------------------------------------|--------------|-------------------------------------------| +| 001 | 2023-05-04 | Draft document for CIP versioning and release policy | Sai Ashrith | | + +**** +<div style='page-break-after: always'></div> + +## 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 image, testing image, partition-encrypted image** etc. in architectures like **x86_64, arm64, armhf**. + +## 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. + * Let us assume that the latest release version is **2.1.1**, then the upcoming regular release version will be **2.2.1**. + +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. The images built after locking the package feeds to a specific snapshot date will be bit-identically reproducible. + +All the releases can be found [here](https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tags). +