Mark deprecation to ubygems.rb for RubyGems 4

[hsbt]

Description:

I'm going to mark deprecate status to obsoleted methods for RubyGems 4

---

Tasks:

• Describe the problem / feature
• Write tests
• Write code to solve the problem
• Get code review from coworkers / friends

I will abide by the code of conduct.

[segiddins]

Where’s the RubyGems issue where we decided to deprecate this?

[hsbt]

@segiddins I don't know. ubygems.rb will never use on the current supported versions of Ruby. It should be removed from this repository.

PS. I already removed its file from ruby core at Ruby 2.5.

[segiddins]

But it’s installed when I Gem update —system, and I don’t think we should remove it without discussing the reason for doing so

[hsbt]

@segiddins Please give a reasonable reason to me to keep its file in the future. I already decided to remove it in RubyGems 4.

[segiddins]

I already decided to remove it in RubyGems 4

I don’t think that’s fair — it’s for the RubyGems team to collectively make decisions, not just you or me.

As to my aversion to removing this file? I run ruby -rubygems frequently

[hsbt]

I run ruby -rubygems frequently

with Ruby 1.8? I wonder why you add -rubygems in 2018.

[hsbt]

1. We already adopted to remove to support old rubies: Release plan for RubyGems 3 & 4 #2191
2. I did NOT remove its file immediately. At first, We warn deprecated message at RubyGems 3. I will remove it at RubyGems 4
3. You did accept other removable pull requests for RubyGems 3 & 4.

I think your opinion is only your experience. It's not reasonable.

[segiddins]

It’s not reasonable to want a discussion, rather than just making changes, saying “a decision has been made”?

[hsbt]

@segiddins I'm waiting "your reasonable reason for this removable change" yet.

After Ruby 1.9, rubygems is automatically activated by the prelude of Ruby. You should not add -rubygems on the technical side. I do not understand your reasons for this problem

[segiddins]

My problem isn't the change per-se, it's the assertion of this has been decided when no discussion has taken place.

You should not add -rubygems on the technical side

a) I run 1.8 occasionally
b) -disable-gems

[hsbt]

a) I run 1.8 occasionally

The current master branch was not supported Ruby 1.8. It was not related this.

b) -disable-gems

Why you add -rubygems with --disable-gems? It's not reasonable.

[segiddins]

Why you add -rubygems with --disable-gems?

Aliases

It was not related this.

It is related. I have scripts that are meant to work on all versions of ruby, and this feels like a breaking change for no good reason

[hsbt]

It is related. I have scripts that are meant to work on all versions of ruby,

It's your personal problem.

[duckinator]

@segiddins is there any reasons your scripts can't be updated to use -rrubygems instead of -rubygems?

@hsbt I'm in favor of deprecating this, but i'd appreciate it if you would consider re-adding it to Ruby until RubyGems removes it. This was a feature for at least 12 years(!), and removing it abruptly like you did in Ruby 2.5 seems risky. We want to provide time for people to adjust their scripts.

[duckinator]

@hsbt what do you think of this message?:

warn "`ubygems.rb' is deprecated, and will be removed on or after 2018-12-01. Remove `-rubygems' from your command-line, or use `-r rubygems' instead"

[hsbt]

👍

[ghost]

Early deprecation notices in advance are good, IMO.

It gives people more time to transition (with a transition period
that should take some time too).

[duckinator]

@hsbt are you going to change the warning? you've got a +1 from me on the deprecation either way, but i don't want to merge it before it's ready if you're changing it.

[hsbt]

@bundlerbot r+

[bundlerbot]

📌 Commit 5f5a0be has been approved by hsbt

[bundlerbot]

⌛ Testing commit 5f5a0be with merge faacaeb...

[bundlerbot]

☀️ Test successful - status-travis
Approved by: hsbt
Pushing faacaeb to master...