microsoft / microsoft/FluidFramework

Require oldestSupportedClient (formerly minVersionForCollab) in Client 3.10

Open
#27,180 0 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

breaking change
Dominant language
TypeScript
Stars
4.9k
Forks
586
Avg merge
1d 15h
Merged PRs (30d)
146

Description

Broken API or pattern

Customer-facing container runtime APIs currently allow the cross-client compatibility choice to be omitted. The canonical property is now oldestSupportedClient, typed as OldestSupportedClientVersion. The deprecated minVersionForCollab property remains accepted temporarily so existing callers can migrate.

Client 3.10 should require callers to provide an explicit compatibility choice. Until the deprecated property is removed by issue #27851, callers should provide exactly one of:

  • oldestSupportedClient (preferred)
  • minVersionForCollab (deprecated)

Supplying neither or both should be rejected at the customer-facing API boundary.

Legacy terminology

Before PR #27806, this setting was named minVersionForCollab and its public type was MinimumVersionForCollab. Those names remain mentioned here for searchability and are tracked for staged removal in issue #27851.

Persisted document-schema fields and telemetry properties continue to use minVersionForCollab; this issue does not rename persisted data or telemetry.

Preparation

The nonbreaking preparation for this requiredness change has landed:

  1. PR #28024 removed now-unused runtime-factory/package code.
  2. PR #28025 migrated active callers to make an explicit compatibility choice while the APIs remain optional.

PR #27971 contains the requiredness implementation and should be refreshed and reviewed for the Client 3.10 breaking-change window before landing.

Generic tests preserve the intended historical behavior through shared compatibility configuration. Feature-specific tests and applications use their actual supported floor.

Internal compatibility exception

The internal static ContainerRuntime.loadRuntime / loadRuntime2 paths may retain their compatibility fallback for cross-version test infrastructure and replay tooling. The goal is to remove omission from customer-facing APIs, not from internal compatibility infrastructure.

Packages

  • @fluidframework/container-runtime — require the compatibility choice on public/beta runtime-loading parameters.
  • @fluidframework/aqueduct — require it on the applicable runtime factory construction APIs.
  • @fluidframework/test-utils and related test packages — provide explicit compatibility choices while preserving intended historical behavior.

Expected timeline

Client 3.10.0

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.