Issue #16345 has been updated by jeremyevans0 (Jeremy Evans).


sam.saffron (Sam Saffron) wrote:
> > I'm against not emitting deprecation warnings by default. 
> 
> I disagree with this, in this case the enormous amount of complaining hurts the ecosystem applies unneeded urgency on people and causes conflict in the community.

I'm OK with eliminating duplicate warnings, or stopping warning after a certain number of warnings emitted.  Not necessarily in favor of either, but either is far superior to not warning at all by default.

> We have been through this previously with secret ENV vars that make Ruby "faster". Forcing people to learn about a magical env var to disable deprecations they have no control over is in the same boat. Besides, this will just end up being reported as a security bug to the security list if left as is, cause docker will eat up all your disk space due to a single call site flooding STDERR forcing logs to grow forever.

Again, this problem better fixed by eliminating duplicate warnings or stopping after a certain number of warnings, compared to not warning at all by default.

> Fixing your own app may be straightforward, in the Discourse case it was just editing a few files, but forcing people to start piling on and pressuring gem authors cause 2.7 is out and now and the gem they released is causing a big pile of warnings and they happen to be on a 3 week break and now they need to hunt down a computer and commit a complex patch cause delegation is now very messy, would not be nice.

There should be pressure on maintainers of popular gems to make sure they continue to work on newer versions of Ruby.  However, there is no urgent need. Gem maintainers have been able to test their code with the master branch for a couple months now and fix possible issues, and preview2 for a few weeks.  If their gem isn't ready for 2.7 before the release of 2.7 final, then there should be no problems with users of the gems continuing to run 2.6 until the gem has been updated.  If they want to use the gem with Ruby 2.7 before the gem has been updated to fix the warnings in 2.7, they should be OK with disabling the warnings manually.

> We have at least a year here to clean up the mess after 2.7 is released, we don't need an artificial urgency here. I am happy to strive to run Discourse deprecation free as soon as possible, but if a gem author takes 2 months to sort this out this is not a huge deal for me. 

It's not a huge deal to me either.  However, it also isn't a huge deal if they have to run Discourse on 2.6 instead of 2.7 until Discourse and Discourse's dependencies are updated. If they want to use it before then, they can add a line of code to disable the warnings if they don't care.

> If we must an alternative here is to release a minor of 2.7 say 9 months from now that flicks the default cause the fire is imminent.

Minor releases of Ruby should only be done to fix bugs, they should not make any feature changes, in my opinion.

I am not one to try to predict the future, but I think it is very likely if warnings are disabled by default in 2.7, and the changes take effect in 3.0, there will be a huge backlash of people complaining that we broke things without proper deprecation warnings when 3.0 is released.  I guess if we'd prefer a huge backlash then than now, disabling the warnings could make sense.  However, I'd rather have annoying warnings now than broken code later.

shyouhei (Shyouhei Urabe) wrote:
> jeremyevans0 (Jeremy Evans) wrote:
> > If an application generates 2 million warnings on Ruby 2.7, that's a huge indication that it needs to be updated, and should not be run in production until it has been updated so it runs without warnings.  If you are running an old/stable gem and it implements any deprecation warnings, those are indications that it needs to be fixed and it should not be run in production on Ruby 2.7 until the warnings are fixed.
> 
> I cannot agree with this paragraph.  This is not how backwards compatibility works.  Running existing codes without any problem is a must.

The logical conclusion of this reasoning is that no deprecation warnings should ever be added, since any deprecation warning could theoretically cause a problem.  However, I don't think that is a good approach. What are your opinions of not warning at all by default compared to eliminating duplicate warnings or stopping after a certain number of warnings?

----------------------------------------
Feature #16345: Don't emit deprecation warnings by default.
https://bugs.ruby-lang.org/issues/16345#change-82682

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
We propose that Ruby doesn't emit deprecation warnings by default.

Deprecation warnings are only useful during development for updating Ruby version.
They are not useful during development with current Ruby.
It is especially frustrating when deprecated warnings are generated in gems.
Also, deprecation warnings are totally useless in production environment.

So, we want to emit deprecation warnings only in useful situations.

We propose a command line argument `-W:deprecated` (or `--warning=deprecated`)
and the following methods to enable/disable deprecation warnings.

```ruby
Warning.disable(:deprecated)
Warning.enable(:deprecated)
Warning.enabled?(:deprecated)
```

Currently we don't propose a method to generate a deprecation warning
because currently our main intent is to disable deprecation warnings for 
keyword arguments, and the warnings are generated in C level.

Background:

We talked about keyword arguments during a developer meeting (2019-11-12).
https://bugs.ruby-lang.org/issues/16333
We expect many deprecation warnings to be generated in Ruby 2.7.
They are not useful except for development for Ruby transition, and
they may block transition to Ruby 2.7.

So, we have consensus to disable deprecation warnings by default.
Our design is intentionally minimum because we need this feature for Ruby 2.7.

We chose `Warning.disable(:deprecated)` instead of
re-defining `Warning.warn` in order to avoid string object generation.

Of course, we expect to extend this feature:
Ruby-level deprecation warning generation,
warnings other than deprecation, 
file-based restriction of warning generation, etc.
But this issue doesn't contain them.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>