0.2.0

Eggup 0.2.0

The lockstep 0.2.0 publication of every Eggup crate. Integrity evidence remains
SHA-256 checksum only — no crate in this release makes an authenticity or
signature claim, and no crate selects a release or authorizes a destination.

Why 0.2.0 and not 0.1.4

eggup-acquisition's next release had to be source-breaking: AcquisitionError::Io(String)
became Io { operation, source } with a live source() chain, and because
std::io::Error implements neither Clone nor PartialEq/Eq the enum now
derives Debug only. A source-breaking seam cannot ship as 0.1.4, and the
workspace is version-lockstep (version.workspace = true in all eight crates),
so the seam's version carried every crate forward with it.

Per-package publication source commits

All seven published from one commit — b612608, which is this tag:

Package	Published from	Registry checksum
eggup-core 0.2.0	b612608 (this tag)	2c86a0eb…eb23b8
eggup-archive 0.2.0	b612608 (this tag)	ce35edd5…ff57ad
eggup-acquisition 0.2.0	b612608 (this tag)	2ef74b4d…299fc3
eggup-curl 0.2.0	b612608 (this tag)	15cf536f…90d3f7
eggup-eggfetch 0.2.0	b612608 (this tag)	9fc8f648…658721
eggup-service 0.2.0	b612608 (this tag)	31dd2e22…fe1b4a
eggup-eggpack 0.2.0	b612608 (this tag)	33dc1da4…14f1f6

The publication order was eggup-core → eggup-archive → eggup-acquisition
→ eggup-curl → eggup-eggfetch → eggup-service → eggup-eggpack,
because a crate is packaged only after every in-workspace dependency it names is
on the registry.

No existing tag was moved. The published 0.1.x versions are not withdrawn:
eggup-curl remains published through 0.1.2 and the other six through
0.1.3.

Three source breaks to plan for

• eggup-acquisition: AcquisitionError::Io(String) is now
  AcquisitionError::Io { operation, source }, and the enum derives Debug
  only — Clone, PartialEq, and Eq are removed. A consumer that matched
  Io(_) must match the struct form; a consumer that cloned or compared whole
  error values must match on the variant and its fields instead.
  eggup-curl and eggup-eggfetch inherit this break transitively through
  their eggup-acquisition ^0.2 requirement, and eggup-eggpack inherits it
  through its exact =0.2.0 pin.
• eggup-service: ServiceError::Manager(detail) is now
  ServiceError::Manager { kind, detail, os_code }, carrying a
  ManagerFailureKind. Match the struct form and branch on kind, not on the
  message text.
• eggup-service: LifecycleUpdateReceipt gained the public field
  engine_policy. The struct has no Default impl, so a consumer that
  constructs it with a struct literal must add the field and stops
  compiling until it does. A consumer that only reads the receipt's fields is
  unaffected.

What the 0.2.0 line closes

• eggup-service 0.1.3 misreported a successful stdin write as a failure.
  The bounded executor consumed the stdin writer's verdict with try_recv,
  which removes the message, so the writer's Ok(()) was discarded and the
  later receive observed an empty, disconnected channel. A crontab - install
  reported manager(Spawn, …) after a write that in fact succeeded. This is
  the first publication that carries the fix.
• eggup-core 0.1.3 had no bounded stdin and an unbounded candidate
  deadline. run_bounded evaluated its documented wall-clock deadline only
  while the direct child was still alive, so a descendant that inherited the
  output pipe could pin the call indefinitely, and the timeout path left both
  reader threads unjoined. eggup-core 0.2.0 adds CommandSpec::stdin_data
  and MAX_STDIN_BYTES, makes the deadline an unconditional maximum bound on
  the whole bounded execution, and classifies a stdin failure by the instant the
  writer observed it.
• eggup-archive's cleanup() success path was unreachable. The shared
  implementation emptied the owned tree and then unconditionally returned
  Err(CleanupFailed). All four entry points now share one truthful contract,
  and Ok(()) is reachable.
• eggup-eggpack no longer runs a second SHA-256 implementation. It
  delegates to eggup_core::hash_file, and its direct sha2 runtime
  dependency is gone.

eggup-service also gained one behaviour change worth reading about: the cron
managed block body must now embed the absolute executable path of the spec, so
a desired_block that omits spec.executable() receives
ServiceError::InvalidInput from inspect, install, and uninstall.

Verification

Every crate was proven from outside this repository: a fresh fixture crate with
no path, git, or patch source, depending on =0.2.0, whose generated lockfile
resolves only from crates.io. The eggup-service fixture resolves
eggup-core 0.2.0 transitively, and the eggup-eggpack fixture resolves all
three of its exact pins at 0.2.0.