(compat) Add PackageCommand to auto update layer compatibility generation

[agarwal-navin]

Description

Each layer within a client (Loader, Driver, Runtime and Datastore) has a generation property which should be incremented monthly. It provides a simple way to determine if two layers are compatible with each other by comparing their generations since layer compatibility is expressed in number of months. For example, between the Runtime and Datastore layers, we support a 3 months compatibility. So, they are compatible if the difference in their generation is <3. See #22877 for more details on how this will work.

This change adds an automated way to increment the generation of these layers for simplicity and consistency. Here is how it works:

• A new PackageCommand called UpdateGenerationCommand is added. The flub command flub generate:layerCompatGeneration can be run this command for a package.
• Added a new node to package.json file called fluidCompatMetadata which will contain the generation information as per the last update. It is of type IFluidCompatibilityMetadata and contains the last generation, last release date and last release package version.
• If the command is run for the first time in a package, it will auto-generate fluidCompatMetadata and add it to the package.json file. It will also auto-generate a filed called layerGenerationState.ts under the .src directory.
• If the command is run subsequently, it will read fluidCompatMetadata from package.json and update the generation (if needed) as follows:
  • If the package version has changed, i.e., a new release has happened, it will update the generation to New generation = Old generation + no. of months since last release.
  • An important requirement is that in between two subsequent releases, the generation should not be incremented by more than the minimum compat window between 2 layers across all layers boundaries. For example, say compat window between Loader / Runtime is 12 months but between Runtime / Datastore it is only 3 months. Then between 2 subsequent releases, generation should not increment by more than 2. If that happens, it doesn't give customers enough time to upgrade their packages and saturate a release before upgrading to the next one. Layer compatiility will break as soon they upgrade.
  • So, the logic for new generation is updated to: New generation = Old generation + min (no. of months since last release, min. compat window between layers across all layer boundaries).
• The flub generate:layerGeneration command will be added to the scripts in client-utils's package.json file in a subsequent PR. The generation information for all the layers will be present in this package. The associated chagnes to the build system to run this command on releases will also be added in a subsequent PR.

AB#51926

[Copilot]

Pull Request Overview

This PR adds automated layer generation updates to the FluidFramework release process. The layer generation system provides compatibility tracking between different client layers (Loader, Driver, Runtime, Datastore) by incrementing a generation number monthly.

• Adds automated generation update logic during minor/major releases
• Creates auto-generated layerGeneration.ts file to track current generation and release date
• Implements logic to calculate new generation based on months elapsed with compatibility window constraints

Reviewed Changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 4 comments.

File	Description
FluidRelease.fsl	Adds DoLayerGenerationUpdate step to release workflow after DoReleaseGroupBump
fluidReleaseStateHandler.ts	Registers the new doLayerGenerationUpdate handler in the state machine
doFunctions.ts	Implements the core layer generation update logic with file I/O and date calculations

[scottn12]

LGTM!

[tylerbutler]

Build break can be fixed by running Pnpm format in the common/build/Eslint config fluid directory.