Adds RFC to remove Ruby from the Jammy Full stack

paketo-buildpacks / rfcs

Apache License 2.0

19 stars 33 forks source link

Adds RFC to remove Ruby from the Jammy Full stack #265

Closed ryanmoran closed 1 year ago

ryanmoran commented 2 years ago

Summary

Readable

Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[x] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

sophiewigmore commented 2 years ago

Based off of this RFC, removing Ruby will have no impact on any of our buildpacks right? If that's the case I'm supportive of this. t will be unfortunate if this change breaks any stacks consumers who have their own buildpacks written in Ruby, but A) I'm not aware of any people doing this at the moment and B) I think the workarounds of using a custom stack, MRI buildpack, or extensions in the future are all reasonable.

sophiewigmore commented 2 years ago

I wonder if there are any other legacy-type packages in the stack that fall under the same category?

robdimsdale commented 2 years ago

@sophiewigmore I think we'd probably want to remove python and a few other libraries too (ubuntu-minimal, libpango1.0-dev, libgraphviz-dev, libgnutls28-dev ?).

I'd be happy with one RFC per library, or one RFC for all. I don't mind either way.

sophiewigmore commented 1 year ago

Notes from working group 11/29:

We include Ruby and Python as a legacy thing, buildpacks in Cloud Foundry were written in those languages once upon a time
This is no longer the case for Paketo buildpacks, its best to remove it
Bump the major version of the stack accordingly
There are enough mitigations to get around this issue.
Removing Python is a longer-term goal, it has more related dependencies we'll need to investigate
Question - the stacks aren't yet at a 1.0.0 version - what version bump should this change be?

robdimsdale commented 1 year ago

As far as the version, I'd like to remove all the packages we think we want to before making a v1.0.0 release. Otherwise we will make a series of breaking changes (and major version bumps) as we identify more packages.

I don't want to go too far the other way - deferring v1.0.0 indefinitely - either, but I think I'd like to keep pre-v1.0.0 once Ruby is removed.

davidmirror-ops commented 1 year ago

2022-12-13 WG Notes: waiting for feedback. Only concern so far is if someone is writing a buildpack relying on Ruby.

sophiewigmore commented 1 year ago

I am fine with this plan, and we can address the more complex Python-related concerns in a separate RFC.

robdimsdale commented 1 year ago

@ryanmoran I think we have 👍 from all the stacks maintainers, so feel free to merge whenever you want.