Skip to content

Mark public enums non_exhaustive and write the DataFusion-coupling semver policy #41

Description

@vyncint

Today#[non_exhaustive] appears three times in the workspace. Public enums that will grow are exhaustive: BackendKind { CpuSimd, Cuda, Metal } (crates/oxidelake-core/src/hardware.rs:16), SessionMode (crates/oxidelake-runtime/src/session.rs:24), Compression (crates/oxidelake-storage/src/parquet_opts.rs:12). OxideFrame::new(DataFrame) / into_inner() and oxidelake_api::prelude re-export DataFusion types (crates/oxidelake-api/src/frame.rs:32,37, lib.rs:37-38), so under ADR-0009 every DataFusion major bump is a breaking change for all nine crates. oxidelake_storage::datagen ships the demo generator in the published library (crates/oxidelake-storage/src/lib.rs:421).

Why it is worth fixing — adding a fourth backend breaks every consumer match on BackendKind; the DataFusion coupling is the right decision and needs a written rule so the semver gate and the CHANGELOG treat the chain bump consistently.

Fix#[non_exhaustive] on BackendKind, SessionMode, Compression, MemoryTier/Tier and any other public enum a match could exhaust; a paragraph in docs/RELEASING.md "What a version number means here": a DataFusion/Arrow major bump is a minor bump of OxideLake before 1.0 and a major after; move datagen behind a datagen feature (default on for the binaries, off for oxidelake-api).

Done whencargo semver-checks reports the enum change as the declared break in the release that ships it; RELEASING.md carries the rule; cargo tree -p oxidelake-api no longer pulls the generator's dependencies without the feature.

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

    enhancementNew feature or request

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions