Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Any-stack Buildpacks #97

Merged
merged 4 commits into from
Aug 21, 2020
Merged

RFC: Any-stack Buildpacks #97

merged 4 commits into from
Aug 21, 2020

Conversation

sclevine
Copy link
Member

@sclevine sclevine commented Jul 27, 2020

@sclevine sclevine requested a review from a team as a code owner July 27, 2020 03:49
Signed-off-by: Stephen Levine <stephen.levine@gmail.com>
@sclevine sclevine force-pushed the any-stack-buildpacks branch from d66fc58 to 31bfc43 Compare July 27, 2020 04:13
@nebhale nebhale requested a review from a team July 28, 2020 15:05
Copy link
Contributor

@nebhale nebhale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm pretty ambivalent about this (it doesn't hurt to be conservative about claimed compatibility), but given that a lot of both Java and NodeJS buildpack integrations are covered by this, it seems like it might be useful.

@nebhale nebhale requested a review from a team July 28, 2020 15:07
# Alternatives
[alternatives]: #alternatives

- We could add a special field that indicates any-stack compatibility, so that buildpack authors need to explicitly opt-in to the new behavior. This would prevent buildpack authors who don't know about stacks from inadvertently declaring any-stack compatibility without adequate testing.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a good compromise. WRT platforms, maybe we just claim a set of stack ids for all, linux, windows? I'm not married to any of those names.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jumping on this bandwagon - if it could harm the UX, I'd rather it be gated/you have to opt in, so that buildpack authors don't ruin users trust in the platform.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@hone
Copy link
Member

hone commented Aug 5, 2020

This is a good addition since I do think many buildpacks can be built to be more generic. I share Ben's concerns of it being the default and would like to see us explore the opt-in options.

@nebhale nebhale requested a review from a team August 5, 2020 18:50
Signed-off-by: Stephen Levine <stephen.levine@gmail.com>
@sclevine
Copy link
Member Author

sclevine commented Aug 7, 2020

Switched to opt-in, ready for review.

text/0000-any-stack-buildpacks.md Outdated Show resolved Hide resolved
@nebhale nebhale requested a review from a team August 12, 2020 15:13
@nebhale
Copy link
Contributor

nebhale commented Aug 12, 2020

Final Comment Period with merge disposition, closing on 19 August, 2020.

sclevine and others added 2 commits August 17, 2020 00:29
Signed-off-by: Stephen Levine <stephen.levine@gmail.com>

Co-authored-by: Ben Hale <bhale@vmware.com>
Signed-off-by: Stephen Levine <stephen.levine@gmail.com>
ekcasey added a commit that referenced this pull request Aug 21, 2020
[#97]

Signed-off-by: Emily Casey <ecasey@vmware.com>
@ekcasey ekcasey merged commit c813829 into main Aug 21, 2020
@ekcasey ekcasey deleted the any-stack-buildpacks branch August 21, 2020 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants