RFC: spec API releases #49
Conversation
ekcasey
force-pushed
the
spec-api-releases
branch
from
9f31de8
to
47fe1da
Compare
text/0000-spec-api-branches.md
Outdated
| [drawbacks]: #drawbacks | ||
|
|
||
| * PRing the spec becomes a more complicated process | ||
| * Core team will have a new resposibility, deciding when to finalize a new API version |
There was a problem hiding this comment.
Would we want to have this fall in line with #33, namely when lifecycle gets released? I can see us dealing with spec changes that wouldn't require a lifecycle release as well.
There was a problem hiding this comment.
imo every lifecycle should fully implement a specific documented set of API versions, but the lifecycle release and the spec release don't need to happen simultaneously.
In other words, if the spec defines buildpack API version 0.3, a subsequent lifecycle release can implement buildpack API 0.2 or 0.3, but it cannot implement half of 0.3 features. Obviously, the preference would be for catching up with the spec as quickly as possible.
text/0000-spec-api-branches.md
Outdated
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - PR all spec changes to master, use release tags to indicate finalized API version |
There was a problem hiding this comment.
I think we can achieve the objectives here with something like this by having a moving stable branch and master is active development. We tell github to use the stable branch as default, so users always see a real API version.
There was a problem hiding this comment.
I like this workflow and I'd like it to coincide with lifecycle releases as deemed necessary. Having the default displayed spec be what is latest also makes a lot of sense. One of the issues today with the spec is that it's misleading and unclear what is implemented and what isn't just by looking at the spec itself. As part of this we should either prioritize or remove features that aren't implemented.
text/0000-spec-api-branches.md
Outdated
|
|
||
| When we want to make several changes to a given API in short succession (i.e. in the time windows between subsequent releases of the reference lifecycle), it would be nice to use a single new API number to represent a set of breaking changes. | ||
|
|
||
| Given that we have decided that master of the spec repo shall always describe a specific set of API versions, we should stage changes on a branch, and merge that branch to master when we want to assign a number to the set of changes. |
There was a problem hiding this comment.
What do we do about changes that are in master today, but aren't implemented?
There was a problem hiding this comment.
with /bin/develop leaving the spec (buildpacks/spec#71), only store.toml remains unimplemented. It's not a particular complicated feature, so I vote we prioritize catching up with the spec before we release the next spec version.
ekcasey
force-pushed
the
spec-api-releases
branch
from
c5c5085
to
3896c48
Compare
text/0000-spec-api-branches.md
Outdated
|
|
||
| The spec repo shall have protected branches representing the next API version (right now those would be `platform/0.3` and `buildpack/0.3`). PRs to the spec that change an API (all non-cosmetic changes) should be made to those branches. | ||
|
|
||
| When they decide it is appropriate, the core team, in consultation with the implementation team will merge an API branch to master, bump the API versions, in the spec README (https://github.com/buildpacks/spec#api-versions), and apply a [tag](https://github.com/buildpacks/spec/releases) to master. |
There was a problem hiding this comment.
Since there are two API versions here, should we clarify/document how we name the tags?
|
I move that this RFC be sent to FCP with a disposition of merge, closing 1700 PT, February 19, 2019. |
ekcasey
force-pushed
the
spec-api-releases
branch
from
4969367
to
ac7e231
Compare
Signed-off-by: Emily Casey <[email protected]> Signed-off-by: Ben Hale <[email protected]>
Signed-off-by: Emily Casey <[email protected]> Co-Authored-By: Terence Lee <[email protected]> Signed-off-by: Ben Hale <[email protected]>
* explicitly calls out that this applies to distribution and current extensions * implies that future extensions will be included in the process Signed-off-by: Emily Casey <[email protected]> Signed-off-by: Ben Hale <[email protected]>
Signed-off-by: Emily Casey <[email protected]> Signed-off-by: Ben Hale <[email protected]>
[resolves #49] Signed-off-by: Ben Hale <[email protected]>
nebhale
force-pushed
the
spec-api-releases
branch
from
ac7e231
to
831c3c6
Compare
[resolves buildpacks#49] Signed-off-by: Ben Hale <[email protected]>
This change causes the buildpack's path to be determined first by reading CNB_BUILDPACK_DIR if it exists. If it does not, fall back to trimming argv[0]. The fallback is temporary and can be removed once the lifecycle supports the primary behavior. [buildpacks/rfcs#49] Signed-off-by: Ben Hale <[email protected]>
Readable
This RFC proposes a branching process to allow us to stage changes for a new platform or buildpack API versions, while accommodating @sclevine's preference that master of the spec always describe a real set of API versions.