Explicitly deprecate rubyforge_project
#2798
Conversation
Because we can't control 3rd party gems using deprecated rubygems behavior, and thus outputting warnings to the screen.
deivid-rodriguez
force-pushed
the
explicitly_deprecate_rubyforge_project
branch
from
8c045da to
9094740
Compare
|
@bundlerbot r+ |
2798: Explicitly deprecate `rubyforge_project` r=bronzdoc a=deivid-rodriguez # Description: In #2436, we removed all the `rubyforge_project` functionality, but kept the gemspec writer as a noop, so that people's gemspecs won't break. However, we didn't deprecate the writer. We should do it, so that we can actually remove it in the future. # Tasks: - [x] Describe the problem / feature - [ ] Write tests - [x] Write code to solve the problem - [ ] Get code review from coworkers / friends I will abide by the [code of conduct](https://github.com/rubygems/rubygems/blob/master/CODE_OF_CONDUCT.md). Co-authored-by: David Rodríguez <[email protected]>
Build succeeded |
ghost
merged commit 
With Rubygems 3.1 we see on JRuby warnings on every gem commands like: ``` NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01. Gem::Specification#rubyforge_project= called from /Users/bti/.rvm/rubies/jruby-head/lib/ruby/gems/shared/specifications/default/json-2.2.0-java.gemspec:18. ``` As a temporary fix we downgrade to 3.0.6, waiting for a json dependency updated. Related: - ruby/rubygems#2798 - ruby/rubygems#2984 (comment)
|
👋 I tried to live on latest rubygems for a while but this change actually makes it really hard. Wouldn't be possible to relax a little on this deprecation, revert back warning for now and just deny rubygems.org pushes having this in gemspec to make ecosystem handle it over the time on its own? Once we will ensure top 100/1000/??? gems are updated, we can roll this out again. I have plan to check top x gems and if hosted on github to open pull requested by script. Anyway it would take some time to let gem maintainers merge those and release new versions. |
|
IMO the problem is not this deprecation itself, but that it is showing up for end users. Deprecations for gemspec attributes should only affect gem authors in my opinion. This is what #3047 intends to fix and it is my plan to review it soon. Also, note that #3108 alleviated this problem since gemspecs are not read for every command. |
|
@deivid-rodriguez thanks for info. Yes, I share the same idea. Gem users can't do anything about that and they just need to wait until this is fixed in gem. Would be nice to move this warning for gem maintainers. Any plan to also reject invalid gemspec (having deprecated options) at rubygems.org? |
|
We have a |
Description:
In #2436, we removed all the
rubyforge_projectfunctionality, but kept the gemspec writer as a noop, so that people's gemspecs won't break. However, we didn't deprecate the writer. We should do it, so that we can actually remove it in the future.Tasks:
I will abide by the code of conduct.