From: "shugo (Shugo Maeda) via ruby-core" Date: 2026-09-18T22:19:48+00:00 Subject: [ruby-core:126786] [Ruby Feature#22304] Add rb_warn_to_remove_at() for deprecation warnings shown by default Issue #22304 has been updated by shugo (Shugo Maeda). Dan0042 (Daniel DeLorme) wrote in #note-6: > Sorry for the trouble, but could you explain why "we should do anyway"? I might be missing something here. A major version bump is a chance to introduce incompatibilities, so I think we should decide for each deprecation whether to keep the schedule or to remove it at the major version. My intention was not to make the schedule fully automatic, but to make it fail-safe. I also see two problems with years: * `RUBY_RELEASE_YEAR` is the date of the commit or the release, so it advances with every patch release, and a compile-time check on it would fail on stable branches. * The yearly release is a convention, not a guarantee. If a release is delayed or skipped, a year-based schedule silently changes its meaning. If we introduce a new macro for the compile-time check instead of `RUBY_RELEASE_YEAR`, a serial number like `RUBY_MINOR_CODE`, which is bumped for each minor version, may be better than a year. ---------------------------------------- Feature #22304: Add rb_warn_to_remove_at() for deprecation warnings shown by default https://bugs.ruby-lang.org/issues/22304#change-119089 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Deprecations such as #22205 and #22276 are scheduled in phases: a warning shown only when `Warning[:deprecated]` is enabled, then a warning shown by default, then the removal. For the first phase, `rb_warn_deprecated_to_remove_at(X.Y, fmt, suggest, ...)` (#17432) prints "... is deprecated and will be removed in Ruby X.Y", and a RUBY_DEBUG build fails to compile when the version reaches X.Y. For the second phase, there is no equivalent API. A warning with the `:deprecated` category is suppressed by default by definition, so the warning must be emitted with `rb_warn` without a category, and the message and the version check have to be written by hand. I propose to add `rb_warn_to_remove_at(X.Y, fmt, suggest, ...)` to internal/error.h: the same message and compile-time check, emitted with `rb_warn`. The name does not contain "deprecated" because `rb_warn_deprecated*` means a warning gated by `Warning[:deprecated]`. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/