Skip to content

feat(cli): show update notice when a newer Data Designer version is available #598

@eric-tramel

Description

@eric-tramel

Priority Level

Medium (Nice to have)

Is your feature request related to a problem? Please describe.

After users can run data-designer --version, the CLI should be able to help them notice when their installed Data Designer version is behind the latest published release. Today there is no CLI or log call-to-action that tells users a newer version is available or how to upgrade.

This matters for support and security-sensitive situations: users may be running an old version with fixed bugs, changed defaults, or yanked dependency constraints without realizing it.

Depends on

Describe the solution you'd like

Extend data-designer --version so that the first line remains the installed version string, then append an update notice only when a newer stable version is available.

Desired base behavior from #597:

0.6.0

Desired behavior when a newer version is available:

0.6.0
╭─ 🚀 Update available ─────────────────────────────╮
│ New Data Designer version available: 0.6.1        │
│ Upgrade with: uv tool upgrade data-designer       │
╰───────────────────────────────────────────────────╯

If the CLI can detect that Data Designer is installed as a project dependency rather than a uv tool, the command should instead point at the project workflow:

0.6.0
╭─ 🚀 Update available ─────────────────────────────╮
│ New Data Designer version available: 0.6.1        │
│ Upgrade with: uv add --upgrade data-designer      │
╰───────────────────────────────────────────────────╯

Implementation expectations:

  • Keep line 1 as the installed version string so simple scripts can still parse the current version.
  • Use Rich styling consistent with the existing terminal UI (rich, panels, existing console/theme helpers, and concise emoji usage).
  • Include the literal phrase New Data Designer version available in the notice.
  • Use a short timeout and fail closed: if the latest version cannot be checked, print only the local version and do not slow down the command materially.
  • Avoid showing prereleases unless the installed version is itself a prerelease or a flag/config explicitly opts into prerelease checks.
  • Cache the result briefly, likely under the existing Data Designer home/config directory, to avoid a network request on every invocation.
  • Provide an opt-out for environments that do not want outbound network checks, for example an environment variable such as DATA_DESIGNER_DISABLE_VERSION_CHECK=1.
  • Add tests covering newer version, current version, network/check failure, opt-out, prerelease handling, and command selection.

Describe alternatives you've considered

  • Showing the update notice on every CLI invocation. This is more proactive, but it risks adding network latency and noise to normal workflows.
  • Logging the update notice during DataDesigner() initialization. This would reach Python API users, but it could surprise notebook/batch workflows and should probably be considered separately after the explicit CLI flow exists.
  • Relying only on package manager output. That does not help users who are debugging through the Data Designer CLI.

Agent Investigation

Current findings from the codebase and open issues:

  • There is no existing Data Designer update-availability check in CLI startup, logging setup, or interface initialization.
  • CLI startup currently only bootstraps default model settings before invoking Typer: packages/data-designer/src/data_designer/cli/main.py and packages/data-designer/src/data_designer/cli/runtime.py.
  • Existing UI helpers already use Rich and emoji-based messages in packages/data-designer/src/data_designer/cli/ui.py.
  • Existing version metadata lookup exists for agent introspection via importlib.metadata.version("data-designer").
  • Docs have an outdated-version CTA for docs pages, but that is separate from installed package version notification: docs/overrides/main.html.
  • I did not find an open issue specifically requesting a new version available CLI/logging CTA.

Additional context

The exact package source can be PyPI or another release source, but it should be chosen deliberately. PyPI is the likely default for data-designer users installed via pip, uv tool, or uv add.

The output should stay useful in both human and automation contexts: local version first, optional human-friendly Rich notice after that.

Checklist

  • I've reviewed existing issues and the documentation
  • This is a design proposal, not a "please build this" request

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions