LoginSign Up
← Back to all sparks
L

lifecycle

INFRA · APIS
Velocity0.0

Manage the lifecycle of R functions and arguments with deprecation warnings

github.com/r-lib/lifecycle ↗

lifecycle gave the tidyverse the word superseded, then spent years tuning who gets warned

deprecationtidyversewarningslintingapi-design
◆Current state
lifecycle defines the deprecation vocabulary the tidyverse signals with - deprecated, superseded, experimental - and the functions that emit those warnings. The design settled early; nearly all work since has been about warning frequency and attribution, deciding who is responsible for a deprecated call and how often they should hear about it.
◆Where it's heading
The consistent problem is blame. Deprecation warnings are useless if they fire at the user of a package rather than its author, so successive releases narrowed the audience: warn only when the deprecated call comes from the package being tested, name the package that likely triggered an indirect usage, and stop repeating. Version 1.0.5 admits the eight-hourly throttle never actually worked and replaces it with once per session.
◆Prediction
Expect further work on the linting side, which is where the recent additions have gone, rather than on the signalling API; signal_stage() being reduced to a no-op suggests staged signals are not coming back.

◆Recent moves

  1. 7mo ago

    Warns once per session; linter covers Quarto files

    Closes out the frequency problem by conceding it: the eight-hourly throttle never worked, so deprecation warnings now fire once per session. signal_stage() is reduced to a pure statement of intent with no behavior, and the linting helpers grow to cover qmd and other literate formats.

    View source ↗
  2. 3y ago

    Indirect deprecations name the package responsible

    The attribution thread in its clearest form: an indirect usage now names the package that likely called the deprecated feature and suggests contacting its authors, and in tests deprecate_soft() stays quiet unless the call comes from the package under test. Warnings land on whoever can act on them.

    View source ↗
  3. 3y ago

    deprecate_warn(always = TRUE) and free-text messages

    Adds a step between a throttled warning and a hard error, letting authors force a warning on every call, and allows arbitrary message text by wrapping the descriptors in I(). Both are escalation controls for a package whose whole job is pacing.

    View source ↗
  4. 4y ago

    Renames last_warnings() to avoid an rlang collision

    A rename to clear the way for a forthcoming rlang function of the same name, plus deprecate_soft() honoring the verbosity option from the global environment. Coordination work, not a change in behavior.

    View source ↗
  5. 5y ago

    1.0.0 documents the stages and eases argument deprecation

    The 1.0.0 release is mostly documentation and syntax: three vignettes covering the stages, how to manage them as a user and how to signal them as an author, plus shorthand for deprecating an argument or an R6 method. The conceptual work had already shipped in 0.2.0.

    View source ↗
  6. 6y ago

    Introduces the superseded stage and signal functions

    ⚡ SPARK

    The release that gave the tidyverse a third option between supported and deprecated. Everything after it - the attribution fixes, the throttle tuning, the linters - is implementation detail on a vocabulary established here.

    View source ↗