[ruby-core:99232] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[ruby-core:99232] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[matz]

Issue #16345 has been updated by matz (Yukihiro Matsumoto).

Status changed from Closed to Open

In https://bugs.ruby-lang.org/issues/16345#note-40, I said it should be on by default, but it turned out they are too noisy.
So I changed my mind. Deprecation warnings should be turned on manually (probably with `-Wdeprecate` or `Waning[:deprecated]=true`).

Matz.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99251] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[akr]

Issue #16345 has been updated by akr (Akira Tanaka).


matz (Yukihiro Matsumoto) wrote in #note-46:

> So I changed my mind. Deprecation warnings should be turned on manually (probably with `-Wdeprecate` or `Waning[:deprecated]=true`).

I'm glad to hear that.

I still think deprecation warnings should not be emitted by default.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99363] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[mame]

Issue #16345 has been updated by mame (Yusuke Endoh).


I'm not sure if this is the right way.

I agree that a deprecation warning is annoying for end users.  I also understand that application developers don't want them to be nervous.
However, disabling the warnings by default does not solve the deprecation issue itself, but just postpone it.  And the issue will be suddenly active when Ruby version is upgraded.  Do people really want to see sudden break?

That being said, now I'm not strongly against the policy change.

* Some people actually complain the deprecation warnings for keyword change.
* The issue can be mitigated if all test frameworks enable all deprecation warnings.
* Sudden break is never a good thing, but may be a very strong motivation to fix applications (though it makes all users more nervous.)

But, I'm still unsure if it is a good practice in total.

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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99364] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[marcandre-ruby-core]

Issue #16345 has been updated by marcandre (Marc-Andre Lafortune).


Deprecation warnings for things that will break in the next version should be on by default (that policy being for Ruby or for gems). If that's too much warnings, then the breaking change should happen more slowly: first version with opt-in deprecation warnings, then version with opt-out deprecations, then breaking change.
It's way too late for that in late July for Ruby 2.7.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99398] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[ko1]

Issue #16345 has been updated by ko1 (Koichi Sasada).


marcandre (Marc-Andre Lafortune) wrote in #note-49:
> If that's too much warnings, then the breaking change should happen more slowly: first version with opt-in deprecation warnings, then version with opt-out deprecations, then breaking change.

+1

Keyword warnings are suddenly introduced exceptionally.
I don't think we choose the policy based on this exceptional case.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99685] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[akr]

Issue #16345 has been updated by akr (Akira Tanaka).


The enabled-by-default deprecation warnings have following effects.
- Good Effect: It makes developers more aware of the problem. (including users noticing and creating a issue)
- Bad Effect: Users ignore warnings or stop ruby upgrade

Since keyword warnings are so common, these effects are outstanding, but the both effects are not specific to keyword warnings.

We can avoid the bad effect and preserve the good effect by
disabled-by-default deprecation warnings and
changing developer's practice to enable deprecation warnings.

The developer's practice can be supported by tools,
such as test frameworks enable deprecation warnings automatically.

I think two-step migration,
disabled-by-default deprecation warnings and enabled-by-default deprecation warnings,
is not good idea.
It is important that developers can choose timing of dealing incompatibilities.
The enabled-by-default deprecation warning forces developers to deal it,
so it limits the timing.


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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99695] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[ko1]

Issue #16345 has been updated by ko1 (Koichi Sasada).


We discussed about it and I recognized the motivation is how to shorten the migration period (to reuse conflicts feature or to delete barrier features) and I understand the advantages of this proposal.
IMO off-by-default and on-by-default should be discussed every time, but I don't against to make it as default policy.

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

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
----------------------------------------
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/

[ruby-core:99783] [Ruby master Feature#16345] Don't emit deprecation warnings by default.

[matz]

Issue #16345 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Closed

I agree with @marcandre for making migration slow(er).  We should wait for a few versions after emitting opt-in warnings before removing the feature. 
But it doesn't affect the discussion of stopping forced (default-on) warnings. I vote for making deprecation warnings basically opt-in.

Matz.


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

* Author: akr (Akira Tanaka)
* Status: Closed
* Priority: Normal
----------------------------------------
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/