From 8b93f620817b881ff105bbe0b228f9321ea0ba4e Mon Sep 17 00:00:00 2001 From: Emily Casey Date: Wed, 14 Aug 2019 12:31:14 -0400 Subject: [PATCH] Use . api version syntax to match PR #19 Signed-off-by: Emily Casey --- text/0000-lifecycle-descriptor.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/text/0000-lifecycle-descriptor.md b/text/0000-lifecycle-descriptor.md index c7028d6ff..f9f5c72df 100644 --- a/text/0000-lifecycle-descriptor.md +++ b/text/0000-lifecycle-descriptor.md @@ -25,13 +25,15 @@ Lifecycle can include a `lifecycle.toml` at it's root. Initially, the only suppo ```toml [api] - platform = "1" - buildpack = "1" + platform = "." + buildpack = "." [lifecycle] - version = "v0.4.0" + version = ".." ``` +The format of a api version would be . or (with a minor of 0 implied). A change to the major version of an API would indicate a non-backwards-compatible change, while a change to the minor version would indicate availability of one or more opt-in features. + When `lifeycle.toml` exists but either of the `api.x` fields is omitted, `pack` will be assume that the lifecycle implements the latest API known to that version of `pack`. When `lifecycle.toml` is omitted, `pack` will initially warn users and assume the lifecycle implements the oldest known api version, for backwards compatibility. Eventually `pack` may require the presence of `lifecycle.toml`. # How it Works @@ -39,16 +41,17 @@ When `lifeycle.toml` exists but either of the `api.x` fields is omitted, `pack` When `pack create-builder` creates a builder. The lifecycle API versions will be added to the `io.buildpacks.builder.metadata` label. +Example: ```json { ... -"lifecycle": {"version": "v0.4.0", "api": {"platform": "1", "buildpack": "1"}} +"lifecycle": {"version": "0.4.0", "api": {"platform": "1.0", "buildpack": "1.1"}} } ``` `pack` would ensure that the `api.buildpack` version matches the `api` version provided by all of the buildpacks that are added to the given builder. -When `pack build` executes, it will check `lifecycle.api.platform` and it will either execute the correct commands for the given platform API, or fail if the platform API version is not supported. For example, if in the future we combine restorer/analyzer and cacher/exporter, then the platform API version of the next lifecycle release would be incremented. This will allow `pack` to know which binaries to execute with which flags. +When `pack build` executes, it will check `api.platform` and it will either execute the correct commands for the given platform API, or fail if the platform API version is not supported. For example, if in the future we combine restorer/analyzer and cacher/exporter, then the platform API version of the next lifecycle release would be incremented. This will allow `pack` to know which binaries to execute with which flags. When `pack build` is run with the `--buildpack` flag, `pack` may use the buildpack api version from the builder metadata to determine whether the buildpack supplied with the `--buildpack` flag is compatible with the builder's lifecycle.