Add RFC to discourage the use of old bionic builders

[c0d1ngm0nk3y]

readable

Summary

Users are still using bionic builders, we should make them aware that they are using a unmaintained stack.

Use Cases

Using paketobuildpacks/builder:base sounds OK and there is no indication that bionic is used and this is not kept up to date.

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.
• [ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[ForestEckhardt]

During the working group meeting, there was a discussion that this functionality might be better handled higher up in the stack and @BarDweller mentioned that he would bring it up in the next buildpacks working group meeting.

One of the ideas that was proposed was to have the CNB project allow us to set a variable when building the builders themselves that would mark them as deprecated. Then it could be up to specific platforms on how they would handle using a deprecated stack (i.e. print a warning, fail the build, mark the resulting image, etc.).

We should discuss the outcome of the upstream conversation in following working group meetings.

[c0d1ngm0nk3y]

Mhhh, doesn't sound too pragmatic too me to be honest. I have 2 concerns...

• We have an issue now with the bionic builders. Later, for the jammy builders, I don't see it as a big problem since the name somehow indicates that you are using jammy. Whereas paketobuildpacks/builder:base sounds like a good idea to use. But it can actually even have some severe consequenses when you look deeper.

• Why should it be up to the platform? I do not see where this complexity will actually help.

My main intention with this issue was to remind users still using paketobuildpacks/builder:base that they should be aware of the risks. But let's see if there are actionable outcomes.

[dmikusa]

If this is something we could act quickly on, I think it would have merit for the project. There are still a lot of Spring users on the old stack because the default won't change until the next release of Spring Boot, which is in a couple of weeks. If we could inject a message to users, that would be very helpful.

That said, if it takes more than a couple of weeks to make that happen, I think the benefit will drop significantly, as users will start upgrading to the latest Spring Boot and will move to Jammy automatically.

A couple of issues come to mind with injecting a new buildpack:

1. It requires us to publish a new bionic builder to include it, and I'm not sure we can do that anymore (at least not without additional overhead). I believe that the projects have been archived and the pipelines taken down.
2. It would require users to update their stack to get that new change.
3. It wouldn't work if users are overriding with custom sets of buildpacks.

The only thing that comes to mind that we could do without publishing new buildpacks/images would be a brown out. Essentially, we advertise ahead of time that we are temporarily taking down the old bionic builders to alert people. Then for a period of a couple of hours, we make the bionic images unavailable. This will break users builds if they are still using them & hopefully get their attention. After the time window expires, we put the images back and if people keep using them, then that's on them.

[c0d1ngm0nk3y]

3. It wouldn't work if users are overriding with custom sets of buildpacks.

It came to me afterwards. That is true :(

we are temporarily taking down the old bionic builders to alert people.

I thought something similar. What about removing the tag and communicating that you can still use the digest instead. Could even be permanently.

[dmikusa]

I thought something similar. What about removing the tag and communicating that you can still use the digest instead. Could even be permanently.

Oh, pulling the tag is a good idea. I wasn't 100% sure how to temporarily disable the image, but that would work well. I'd say we start with a temporary removal to get people's attention, with possibly a permanent one down the road. That would enable people to keep using it if they really, really need to but definitely requires opt-in.

I don't personally feel like we need an RFC for this approach, but just a vote across the steering committee & maintainers. If the majority are in favor, then we can make that happen. If others feel differently, please let us know.

[loewenstein]

I thought something similar. What about removing the tag and communicating that you can still use the digest instead. Could even be permanently.

Oh, pulling the tag is a good idea. I wasn't 100% sure how to temporarily disable the image, but that would work well. I'd say we start with a temporary removal to get people's attention, with possibly a permanent one down the road. That would enable people to keep using it if they really, really need to but definitely requires opt-in.

I don't personally feel like we need an RFC for this approach, but just a vote across the steering committee & maintainers. If the majority are in favor, then we can make that happen. If others feel differently, please let us know.

Why would you go for a temporal removal first, if our goal is to force opt-in. If that is to make sure that even inattentive users get their pipelines working again eventually? What would then be the condition to later permanently disable?

Maybe we can permanently disable the tags and at the same introduce replacements with an -unsafe suffix? That's more convenient than copying a digest, but we don't want to apply too much force that just leads to frustration.

[dmikusa]

My thought with a temporary removal first would be to attempt to get people's attention. We'll of course make announcements in advance, but inevitably people won't see our announcements. The temporary brown-out is a way to get more attention. Things go back to the way they were so if it really, really causes issues for someone then they have a little more time to address the problem before we permanently make the change.

If folks feel like that's unnecessary, we could skip it and make a permanent change. I don't have strong feelings one way or the other.

[loewenstein]

My thought with a temporary removal first would be to attempt to get people's attention. We'll of course make announcements in advance, but inevitably people won't see our announcements. The temporary brown-out is a way to get more attention. Things go back to the way they were so if it really, really causes issues for someone then they have a little more time to address the problem before we permanently make the change.

If folks feel like that's unnecessary, we could skip it and make a permanent change. I don't have strong feelings one way or the other.

I don't have a strong opinion either. Just thought what the difference would be - whoever missed the first call will still be broken by the later permanent removal. But yeah, even a convenient base-unsafe tag would need to be set and projects might have an enforced code freeze that makes even something like that difficult.

[c0d1ngm0nk3y]

I don't personally feel like we need an RFC for this approach,...

I agree. Should I just close it?

[dmikusa]

Yes, let's close. This is out plan moving forward.

[sophiewigmore]

Update from WG meeting 11/28 - attendees are good to close this RFC out

[ForestEckhardt]

@c0d1ngm0nk3y Are you ok with closing out this RFC?

[c0d1ngm0nk3y]

@c0d1ngm0nk3y Are you ok with closing out this RFC?

Yes :)