Skip to content

Define canonical packaging for development framework sources #10

Description

@infoconex

Problem

Windows bootstrap development runs currently resolve a framework Git ref to an immutable commit, extract .flywheel, and create an install-ready ZIP. The exact generated ZIP is hashed and recorded in installation provenance, but repeated repackaging of the same immutable framework commit can produce different ZIP SHA-256 values because ZIP byte representation depends on metadata/compression behavior.

Why this should not be solved only in the Windows wrapper

A truly canonical package requires a contract for file ordering, path normalization, timestamps, attributes, compression method/version, and cross-runtime behavior. That belongs in the framework/CLI packaging contract rather than being invented independently by the Windows bootstrap.

Current provenance remains traceable because development sources record both the resolved immutable framework commit and the SHA-256 of the exact package installed.

Proposed follow-up

  • Decide whether development/local framework packaging must be byte-reproducible.
  • If yes, define one canonical packaging algorithm and ownership boundary.
  • Implement canonical packaging in the CLI or framework release/package tooling rather than separately in each bootstrap.
  • Add reproducibility tests across supported runtimes/platforms.
  • Preserve resolved source commit/ref plus exact installed-package SHA in provenance.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions