Skip to content

Investigate and fix minimum_version semantics in trezorlib #7345

Description

@coderabbitai

Summary

Investigate and correct the semantics and use of per-model minimum_version in trezorlib.

PR #7212 consolidates model metadata in python/src/trezorlib/_modeldata/ and adds model-specific minimum firmware versions. During review, it was noted that trezorctl warns that firmware is outdated whenever this threshold is not met. That behavior may not be appropriate if these values represent the first firmware release for a model rather than a mandatory upgrade floor.

Required investigation

  • Define the intended contract for ModelData.minimum_version:
    • whether it is the first released firmware version,
    • a minimum supported firmware version for host operations,
    • or another compatibility threshold.
  • Trace every trezorlib and trezorctl consumer of this metadata and document how it affects user-visible warnings and behavior.
  • Decide whether the field should be enforced, renamed, split into distinct metadata, or removed until there is a valid use case.
  • Ensure the model values are accurate if the field remains.

Affected areas

  • python/src/trezorlib/_modeldata/
  • python/src/trezorlib/models.py
  • Firmware/CLI version-checking and warning paths in python/src/trezorlib/

Acceptance criteria

  • The meaning of minimum_version is documented and unambiguous.
  • trezorctl does not emit misleading “outdated firmware” warnings based solely on model-release metadata.
  • All consumers implement the agreed semantics consistently.
  • Tests cover the intended warning/compatibility behavior and the relevant model-version cases.

Requested by @obrusvit.

Related:

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status
No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions