Aglet

Triage version skew across a release boundary

Version skew can be expected during a transition or harmful when contracts changed. Begin with the versions actually serving each path and compare them with the intended release sequence. Keep compatibility assumptions explicit because labels alone do not show behavior.

Establish what is happening

  1. Inventory served versions

    Record service, worker, environment, repository, commit, artifact, and observed version for each relevant path. Prefer immutable identifiers and timestamps, and mark records that describe desired state rather than served state.

  2. Find the incompatible boundary

    Map requests, jobs, events, or data flows between components and identify where version pairs meet. Note the contract, schema, or feature expectation that may differ, without asserting incompatibility before evidence.

  3. Bound exposure

    Describe which users, regions, queues, or environments can encounter the version pair and whether skew is brief, persistent, or expanding. Separate harmless rollout overlap from a path with observed failures.

What to carry forward

Triage should state the version pair, interaction boundary, affected exposure, and evidence still missing. Escalate when a real path shows incompatible outcomes or the skew boundary is unknown; do not label ordinary transition overlap as a regression by default. Write down whether each version is desired, deployed, or observed in traffic; mixing those meanings can make a normal transition look like an incompatible pair.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow