Skip to content

[documentation-writing-alignment] Reconcile API-fingerprint versioning claims with the resolver #577

Open

Description

Context and request

Module maintainers need a versioning reference that distinguishes approved policy from verified release-decision implementation. This protected factual scope is split from #562 so grammar, en-US, and shorter descriptive prose can proceed without inventing an API-comparison mechanism.

Evidence and source boundary

At 64ffb1d87f86bd5d487891fdb140b78385a00531, reference/versioning.md, blob ee2eafdd83405ab42da7a25aa5f6e9ff367e6d5e, lines 127-155 describe future custom scripts that compare exported API fingerprints and choose version bumps. The conclusion repeats an automation claim. The actual Resolve-PSModuleVersion release-decision boundary uses resolved settings and PR labels; #359 and #524 retain the settings/default producer decisions.

The integration coordinator does not release the fingerprint mechanism passage for a factual rewrite. A future-to-present tense substitution is not evidence that the mechanism exists. The separate no-mocks and core-only-major decisions remain #563 and #573.

Acceptance criteria

  • Identify the authoritative supported version-decision implementation and exact source identities after the owning settings/default decisions.
  • Establish whether an approved, implemented fingerprint mechanism exists; distinguish requirements or proposed mechanisms from observed implementation.
  • Reconcile the dedicated fingerprint section and any related automation claim in the page with that evidence, after owner coordination.
  • Preserve the actual SemVer policy, compatibility classifications, public names, examples, version constraints, and normative force unless a separate policy decision authorizes change.
  • Do not claim automatic policy enforcement from a requirement, an intended script, an external article, or a passing prose check.
  • One focused documentation draft PR records the source comparison and acceptance evidence. No versioning mechanism, producer migration, or runtime change is implemented by this Task.

Technical decisions and readiness

This Task owns the reference's factual conformance, not the underlying resolver implementation or the work already owned by #359 and #524. Retain the protected section until the exact mechanism/status decision is supported. Preserve external quotations and article attribution. Follow the pinned Documentation Model and Writing Guide.

Implementation plan

  • Trace the real settings/label resolver and the approved mechanism decision; capture immutable source evidence before editing.
  • Compare every fingerprint/automation claim with that evidence and record the expected wording property or unresolved owner decision.
  • Obtain the bounded factual handback; do not wake/amend held proposal branches or choose the separate mock/major policies.
  • Correct only the approved reference claims in one focused draft PR, with no runtime or interface change.
  • Verify preserved policy, examples, identifiers, external quotations, and existing Markdown/link/site checks; record remaining limits explicitly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions