Hide patchlevel from lockfile

[hsbt]

What was the end-user or developer problem that led to this PR?

The ruby core team consider to stop to increase RUBY_PATCHLEVEL each commits on stable branch like ruby_3_3.

It means comparison feature of patchlevel and show patchlevel are meaningless in lockfile of Bundler. We already hide patchlevel with ruby -v from Ruby 3.2.

What is your fix for the problem, implemented in this PR?

I also removed patchlevel from lockfile and comparison condition of patchlevel. It's good time to remove that at this year because Ruby 3.1 will be EOL at next year.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

How will old versions of Bundler deal with lockfiles without patchlevel?

[hsbt]

In my understanding, lockfile of non patchlevel version is only available Bundler 2.6.x or later because auto-switching feature enable it.

[deivid-rodriguez]

Yeah, however, recent experience has proven that this is not always the case in real life. For example, Heroku uses a fixed version of Bundler that's usually older than what's in lockfile's "BUNDLED WITH". Dependabot too will also start creating lockfiles without patchlevel without changing the "BUNDLED WITH" section. Also, users may disable the auto-switching feature, or just bugs like #7719 or #7778 may prevent the switch.

Ideally we would apply this only to new lockfiles, and warn old lockfiles with some command to explicitly remove the patchlevel. But maybe this is not necessary and old versions deal with this fine, we should try.

That said, if we hold releasing this to Bundler 2.6.x and tag it as a small breaking change, then we may not take as many precautions.

[hsbt]

I have no idea that good way for that yet. Should we backport to Bundler 2.4 and 2.5 and release them?

[deivid-rodriguez]

I would hold on releasing this until we find answers to these questions. I can dig in more next week.