RFC: Lifecycle descriptor #20
Conversation
ekcasey
requested review from
hone,
jkutner,
sclevine,
nebhale,
jromero and
ameyer-pivotal
Signed-off-by: Emily Casey <ecasey@pivotal.io>
ekcasey
force-pushed
the
lifecycle-descriptor
branch
from
cdd060b to
b39c5cf
Compare
| platform = "1" | ||
| buildpack = "1" | ||
|
|
||
| [lifecycle] |
There was a problem hiding this comment.
Wonder if a top-level lifecycle field would be necessary. I guess we do the same for buildpack.toml, so it's probably fine.
ekcasey
force-pushed
the
lifecycle-descriptor
branch
from
e17a595 to
30c5dd1
Compare
| ```toml | ||
| [api] | ||
| platform = "<major>.<minor>" | ||
| buildpack = "<major>.<minor>" |
There was a problem hiding this comment.
It does seem that having a single api version in #19 would make defining support in lifecycle a better experience. Is it possible that a user wants a combination of two versions (platform and buildpack) where there is not lifecycle version that matches?
I guess my point is: the purpose of two api versions is to prevent people from having to unnecessarily bump both when only one has changed. But unless we plan on supporting version ranges, people may end up having to bump both anyways.
There was a problem hiding this comment.
The reason I think defining two version is important is that a breaking change in the platform/lifecycle interface doesn't necessarily imply a breaking change in the lifecycle/buildpack interface and vice versa. If we only had one api version, something like change a detector flag name would require every buildpack author to bump the api version in their buildpack.toml to indicate compatibility with the new lifecycle. That doesn't seem right to me.
Signed-off-by: Emily Casey <ecasey@pivotal.io>
ekcasey
force-pushed
the
lifecycle-descriptor
branch
from
30c5dd1 to
8b93f62
Compare
text/0000-lifecycle-descriptor.md
Outdated
| version = "<major>.<minor>.<patch>" | ||
| ``` | ||
|
|
||
| The format of a api version would be <major>.<minor> or <major> (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. |
There was a problem hiding this comment.
I think I understand where this is going, but can we just add another line from what we clarified in the working group today that says: supporting api version 1.2 means supporting 1.0, 1.1, 1.2, but not 1.3. This way we get built in version ranges based off of sem ver which handles most of the cases I think we'd want.
* components specifying differents minor versions of an api also support all previous minors Signed-off-by: Emily Casey <ecasey@pivotal.io>
|
After the WG discussion today, I'm 👍 on the two version split, but I imagine for buildpack developers they'll mostly be concerned about the buildpack/lifecycle contract. We can figure out a way to market the versions that matter to the right audiences. As an operator, I imagine I'll need to care about both versions. |
typo fix Co-Authored-By: Terence Lee <hone02@gmail.com>
Signed-off-by: Emily Casey <ecasey@pivotal.io>
|
|
||
| The format of a api version would be <major>.<minor> or <major> (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 additional features. For example, a lifecycle that specifies version 1.2 of the buildpack api supports buildpacks that specify versions 1.0, 1.1, 1.2, but not those that specify 1.3. | ||
|
|
||
| When `lifecycle.toml` exists, both of the`api.x` fields are required. When `lifecycle.toml` is omitted, `pack` will warn users and assume the lifecycle implements the oldest known api version, for backwards compatibility. Eventually `pack` may require the presence of `lifecycle.toml`. |
Signed-off-by: Emily Casey ecasey@pivotal.io
Readable
NOTE: depends on #19