bug: dav-server-opendalfs needs incompatible version bumps for public dependency upgrades

[ngg]

OpenDAL version or commit

dav-server-opendalfs 0.7.5 → 0.7.6

Affected service or component

integrations/dav-server and release versioning

Describe the bug

0.7.6 upgrades opendal-core from ^0.58.1 to ^0.59.0, but OpendalFs::new and the public op field expose its Operator type. This breaks downstream code during an otherwise compatible patch update: an application's 0.58.x operator cannot be passed to the updated integration.

Steps to Reproduce

Create a library with cargo new --lib dav-semver-repro. Add these dependencies:

[dependencies]
dav-server-opendalfs = "0.7.5"
opendal-core = { version = "=0.58.1", default-features = false }

Replace src/lib.rs with:

use dav_server_opendalfs::OpendalFs;
use opendal_core::Operator;

pub fn wrap(op: Operator) -> Box<OpendalFs> {
    OpendalFs::new(op)
}

Run inside the project:

cargo update -p dav-server-opendalfs --precise 0.7.5
cargo check --locked # succeeds
cargo update -p dav-server-opendalfs --precise 0.7.6
cargo check --locked # fails

Verified on Windows x86_64 with Rust/Cargo 1.98.1, using cached published crates with --offline.

Actual Behavior

The second check fails with E0308: expected Operator, found a different Operator. Cargo resolves opendal-core 0.59.2 for the integration alongside the application's 0.58.1.

Expected Behavior

An incompatible upgrade of the exposed opendal-core dependency should require an incompatible dav-server-opendalfs bump: here, 0.7.5 → 0.8.0. Please enforce this in release version planning and validation.

Additional Context

Recent dependency requirements from release history:

DAV version	opendal-core requirement
0.7.4	^0.58.1
0.7.5	^0.58.1
0.7.6	^0.59.0
0.7.7	^0.59.1
0.7.8	^0.59.2

The incompatible change landed in #8208. Earlier 0.7.1–0.7.3 releases also used patch bumps for incompatible opendal upgrades.

Release tooling already registers public compatibility dependencies for object-store and Parquet, but omits DAV.

Reproduction confirmation

• I reproduced this issue against the affected component. For a service-specific report, I used the actual service rather than only a mock, emulator, or source-code analysis.

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.