Skip to content

Audit externally extensible public enums and identities for 1.x semver #256

Description

@Teakowa

Parent: #252

Goal

Ensure public Rust types that model Overwatch-owned, externally extensible domains can grow during 1.x without avoidable downstream breaking changes, while keeping genuinely closed Workshop concepts simple.

Context

workshop-rs already uses open string-backed identities where the external domain is expected to grow, such as hero and gameplay identifiers. Other public domains are represented as closed Rust enums. Adding a variant to a public enum can break exhaustive downstream matches even when the underlying Workshop change is additive.

The 1.0 boundary should distinguish domains WrightKit controls and can intentionally keep closed from domains Blizzard can extend independently. The goal is not to make every enum open or add #[non_exhaustive] mechanically; each change must be justified by the actual domain contract.

Scope

  • Inventory public enums and closed identity types in the intended 1.0 surface.
  • Classify whether each domain is genuinely closed by the workshop-rs contract or externally extensible with future Overwatch updates.
  • For externally extensible domains, choose the smallest representation that permits additive future concepts without unnecessary major-version churn: open identity, generic canonical representation, or #[non_exhaustive] where appropriate.
  • Preserve exhaustive matching for genuinely closed internal/domain invariants where it improves correctness and does not create an external evolution hazard.
  • Check downstream WrightKit consumers for exhaustive matches before changing representation.
  • Add tests only where they protect the resulting public contract or a real regression.

Non-goals

  • Applying #[non_exhaustive] to every public enum.
  • Replacing simple enums with string IDs when the domain is genuinely closed.
  • Predicting hypothetical Blizzard features without a concrete extensibility boundary.
  • Redesigning the canonical Program model.
  • Adding extension registries or plugin systems.

Acceptance criteria

  • Public enums/closed identity types in the intended 1.0 surface are reviewed against actual Workshop ownership and external extensibility.
  • Domains that can grow independently of WrightKit have a 1.x-compatible additive representation strategy.
  • Genuinely closed domains remain simple rather than being generalized speculatively.
  • WrightKit-owned consumers are checked for exhaustive matches and migrated where required before the owner API change lands.
  • Relevant semantic/public API tests pass and protect the intended contract rather than implementation details.
  • The audit does not introduce registries, extension protocols, or other speculative machinery.

Dependencies / ownership

Activity

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

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions