search

dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.61k stars 981 forks source link

Drop support for Bundler 1 #6457

Open jeffwidman opened 1 year ago

jeffwidman commented 1 year ago

Today we support both Bundler v1 and v2.

At some point we'll stop supporting Bundler v1 here in dependabot-core entirely as we're a small team so can't maintain deprecated ecosystems forever.

Re: timing... Although I couldn't find an official deprecation notice for Bundler v1, upgrading to Ruby 3.2 breaks Bundler v1:

A potential workaround is using Bundler v2 to handle updating Bundler v1 configs:

If the workaround is straightforward, then it's not urgent, so may stick around for a while, depending on whether our metrics show it's a commonly used ecosystem or not.

So this is a placeholder ticket to track any discussions around timing, things that we'll need to update/remove, etc.

If you're a user of Dependabot who is still on Bundler v1 and you cannot upgrade to Bundler v2 for some reason, please chime in here explaining your use case.

jeffwidman commented 1 year ago

From @deivid-rodriguez in https://github.com/dependabot/dependabot-core/pull/6436#issuecomment-1382697809:

One issue is indeed what to do with Bundler 1. I see several options:

  1. Drop support for Bundler 1 before upgrading to Ruby 3.2. That effectively blocks the Ruby upgrade until we decide we're ready to drop Bundler 1.

  2. Monkey patch Bundler 1 to remove all taint/untaint. This seems doable but messy, specially since I think this is used in quite a few places.

  3. Let Bundler 2 also update lockfiles created with Bundler 1. This sounds a bit like cheating but I think it should be fine because the lockfile format has not really changed between Bundler 1 and Bundler 2.

I think the latter may be the best course of action because it allows us to effectively get rid of Bundler 1 internally, while still being able to provide updates to lockfiles locked to Bundler 1.

Option 3 does sound like the best course of action if it's straightforward. That said, if it's very much work, then we should probably first collect metrics on how much Bundler v1 is actually even used before investing much time into it...

The new Dependabot Paused feature is still rolling out, but once it does that will provide far more accurate metrics because then we are only measuring activity where people are actively using Dependabot... versus currently any metrics may include where Dependabot has been opening/closing PR's against old abandoned repos (which are more likely to be using Bundler v1).

deivid-rodriguez commented 1 year ago

I think it should be a pretty straightforward change. I'll allocate some time to evaluate it better.

jeffwidman commented 1 year ago

When we drop support for Bundler 1 we can also drop: https://github.com/dependabot/dependabot-core/pull/7786/files#diff-8fa2e59ed1b104d83c365010bcd2db2ed24eeb58b3136bf9fc5df358bf7a7ad2R22-R23