Skip to content

feat: workspace version check — compatibility floor + staleness warning (R2) #118

Description

@Jammy2211

Overview

R2 of the version-pinning design review (PyAutoLabs/PyAutoBuild#118). check_version() currently raises WorkspaceVersionMismatchError on exact inequality between installed library and workspace-recorded version — maximally brittle under the reinstated daily release cadence, and its advice can tell users to pin-install yanked versions. This task replaces exact-match with a compatibility floor: raise only when the installed library is older than what the workspace requires; warn (never raise) when the workspace clone looks stale.

Autonomy: --auto, effective supervised (feature cap). Plan recorded here; run proceeds; ship sign-off will park with a batched question per the contract.

Plan

  • Workspace records version.minimum_library_version in config/general.yaml; check becomes installed >= minimum.
  • Legacy records (version.workspace_version, version.txt) are reinterpreted as floors — the common "old clone, newer library" case passes instead of hard-failing.
  • Add a staleness warning (never an exception) when the installed library is >30 days newer than the recorded floor.
  • Rewrite advice text: never recommend exact == pins (may be yanked); recommend plain upgrade / git pull / the existing bypasses.
  • Keep both bypasses and cwd-based discovery; extend test_autoconf for the new semantics.
Detailed implementation plan

Affected Repositories

  • PyAutoConf (primary; downstream libraries call check_version on import but its signature is unchanged)

Branch Survey

Repository Current Branch Dirty?
./PyAutoConf main clean

Suggested branch: feature/version-check-compat-floor
Worktree root: ~/Code/PyAutoLabs-wt/version-check-compat-floor/

Implementation Steps

  1. autoconf/workspace.py:
    • Resolve the floor with precedence version.minimum_library_versionversion.workspace_versionversion.txt.
    • _parse_version date-tuple comparison: raise WorkspaceVersionMismatchError only when installed < floor; unparseable versions (dev installs, arbitrary strings) fall back to a warning on inequality, never a raise.
    • Staleness path: both versions parseable and installed's (Y, M, D) date is >30 days after floor's → warnings.warn advising git pull (and floor-bump if deliberate).
    • New advice text: pip install --upgrade <library> (no == pin anywhere), git pull origin main, bypass instructions unchanged; keep the directional logic from PyAutoConf#107 but floor-aware.
  2. test_autoconf/test_workspace.py (or the existing test module): cover — floor satisfied (equal / newer installed), installed below floor (raises), legacy exact key as floor, staleness warning >30 days, unparseable version warn-not-raise, both bypasses, missing records warning. numpy-only, no JAX.
  3. Full suite python -m pytest test_autoconf/.

Key Files

  • PyAutoConf/autoconf/workspace.pycheck_version, _mismatch_message, _parse_version
  • PyAutoConf/test_autoconf/ — new/extended workspace-check tests

Out of scope (follow-ups)

  • Workspace general.yaml adoption of minimum_library_version (workspace task after this ships).
  • Release-pipeline changes to stop writing workspace versions (R3, PyAutoBuild).

Original Prompt

Click to expand starting prompt

R2 of PyAutoBuild#118 (endorsed 2026-07-08): make the workspace check a compatibility window, not equality — workspace records a minimum required library version (bumped deliberately, only when scripts start depending on new API — not by the release cron), check installed >= minimum, and warn (never raise) when the library is much newer than the workspace clone (e.g. >30 days by date-version comparison). This preserves the wrong-pairing protection while eliminating the daily-mismatch storm and removing the release pipeline's need to touch workspace repos at all.

User go-ahead: "ok, those PRs are done so we can do this work now --auto"

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    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