For context on how the CNB project thinks about versioning, see RFC#10 and RFC#11. The CNB project versions our spec components and implementations following separate schemas, detailed below:
The spec describes two components that are separately versioned. These APIs are versioned as follows:
Given by CNB platforms to the lifecycle, this version indicates which platform API versions that platform currently support. In review, in PR#67, this version indicates the compatibility between a CNB platform and a given lifecycle according to the following rules:
- When
<major>is0, the platform is only compatible with lifecycles implementing that exact Platform API. - When
<major>is greater than0, the platforms is only compatible with lifecycles implementing platform API<major>.<minor>, where<major>of the lifecycle equals
Documented in the buildpack spec this field indicate compatibility with a given lifecycle according to the following rules:
- When
<major>is 0, the buildpack is only compatible with lifecycles implementing that exact buildpack API. - When
<major>is greater than 0, the buildpack is only compatible with lifecycles implementing buildpack API<major>.<minor>, where<major>of the lifecycle equals<major>of the buildpack and<minor>of the lifecycle is greater than or equal to<minor>of the buildpack.
We aim to release the core implementations of the project at a time-based cadence, per buildpacks/rfcs#33. These implementations are versioned as follows:
- Pack: Pack is released via Github releases and its versions follow semver conventions.
- Lifecycle: Pack is released via Github releases and its versions follow semver conventions.
- libcnb: libcnb is released via Github releases and its versions follow semver conventions.