build: Remove changelog entries for reverted change (#23139)

Removes changelog entries for the reverted changes in #23133. Also removes some lingering entries in the release notes from that same change. Finally, also fixes up some heading levels in the release notes and TOC that were missed in review.
microsoft · Nov 19, 2024 · 50cb876 · 50cb876
1 parent b92a003
commit 50cb876
Show file tree

Hide file tree

Showing 3 changed files with 3 additions and 144 deletions.
diff --git a/RELEASE_NOTES/2.10.0.md b/RELEASE_NOTES/2.10.0.md
@@ -7,13 +7,6 @@
 - [✨ New Features](#-new-features)
   - [New compareFluidHandle function for comparing FluidHandles (#22997)](#new-comparefluidhandle-function-for-comparing-fluidhandles-22997)
   - [SharedString DDS annotateAdjustRange (#22751)](#sharedstring-dds-annotateadjustrange-22751)
-  - [Key Features and Use Cases:](#key-features-and-use-cases)
-  - [Configuration and Compatibility Requirements:](#configuration-and-compatibility-requirements)
-  - [Usage Example:](#usage-example)
-- [Overview](#overview)
-- [Key Benefits](#key-benefits)
-- [Use Cases](#use-cases)
-  - [Example 1: Creating a Child Datastore](#example-1-creating-a-child-datastore)
 - [🌳 SharedTree DDS Changes](#-sharedtree-dds-changes)
   - [Provide more comprehensive replacement to the `commitApplied` event (#22977)](#provide-more-comprehensive-replacement-to-the-commitapplied-event-22977)
   - [SharedTree event listeners that implement `Listenable` now allow deregistration of event listeners via an `off()` function. (#23046)](#sharedtree-event-listeners-that-implement-listenable-now-allow-deregistration-of-event-listeners-via-an-off-function-23046)
@@ -51,17 +44,17 @@ This update introduces a new feature to the `SharedString` DDS, allowing for the
 
 An adjustment is a modification applied to a property value within a specified range. Adjustments can be used to increment or decrement property values dynamically. They are particularly useful in scenarios where property values need to be updated based on user interactions or other events. For example, in a rich text editor, adjustments can be used for modifying indentation levels or font sizes, where multiple users could apply differing numerical adjustments.
 
-### Key Features and Use Cases:
+#### Key Features and Use Cases:
 
 - **Adjustments with Constraints**: Adjustments can include optional minimum and maximum constraints to ensure the final value falls within specified bounds. This is particularly useful for maintaining consistent formatting in rich text editors.
 - **Consistent Property Changes**: The feature ensures that property changes are consistent, managing both local and remote changes effectively. This is essential for collaborative rich text editing where multiple users may be making adjustments simultaneously.
 - **Rich Text Formatting**: Adjustments can be used to modify text properties such as font size, indentation, or other formatting attributes dynamically based on user actions.
 
-### Configuration and Compatibility Requirements:
+#### Configuration and Compatibility Requirements:
 
 This feature is only available when the configuration `Fluid.Sequence.mergeTreeEnableAnnotateAdjust` is set to `true`. Additionally, all collaborating clients must have this feature enabled to use it. If any client does not have this feature enabled, it will lead to the client exiting collaboration. A future major version of Fluid will enable this feature by default.
 
-### Usage Example:
+#### Usage Example:
 
 ```typescript
 sharedString.annotateAdjustRange(start, end, {

diff --git a/packages/runtime/container-runtime/CHANGELOG.md b/packages/runtime/container-runtime/CHANGELOG.md
@@ -23,73 +23,6 @@
     -   Alternatives to calling `IDeltaManager.inbound.pause`, `IDeltaManager.outbound.pause` for `IContainer` disconnect use `IContainer.disconnect`.
     -   Alternatives to calling `IDeltaManager.inbound.resume`, `IDeltaManager.outbound.resume` for `IContainer` reconnect use `IContainer.connect`.
 
--   Enable Synchronous Child Datastore Creation ([#22962](https://github.com/microsoft/FluidFramework/pull/22962)) [67b5e4dca8](https://github.com/microsoft/FluidFramework/commit/67b5e4dca8ae7ae2b2878ecb289e08624f467129)
-
-    ## Overview
-
-    This feature introduces a new pattern for creating datastores synchronously within the Fluid Framework. It allows for the synchronous creation of a child datastore from an existing datastore, provided that the child datastore is available synchronously via the existing datastore's registry and that the child's factory supports synchronous creation. This method also ensures strong typing for the consumer.
-
-    In this context, "child" refers specifically to the organization of factories and registries, not to any hierarchical or hosting relationship between datastores. The parent datastore does not control the runtime behaviors of the child datastore beyond its creation.
-
-    The synchronous creation of child datastores enhances the flexibility of datastore management within the Fluid Framework. It ensures type safety and provides a different way to manage datastores within a container. However, it is important to consider the overhead associated with datastores, as they are stored, summarized, garbage collected, loaded, and referenced independently. This overhead should be justified by the scenario's requirements.
-
-    Datastores offer increased capabilities, such as the ability to reference them via handles, allowing multiple references to exist and enabling those references to be moved, swapped, or changed. Additionally, datastores are garbage collected after becoming unreferenced, which can simplify final cleanup across clients. This is in contrast to subdirectories in a shared directory, which do not have native capabilities for referencing or garbage collection but are very low overhead to create.
-
-    Synchronous creation relies on both the factory and the datastore to support it. This means that asynchronous operations, such as resolving handles, some browser API calls, consensus-based operations, or other asynchronous tasks, cannot be performed during the creation flow. Therefore, synchronous child datastore creation is best limited to scenarios where the existing asynchronous process cannot be used, such as when a new datastore must be created in direct response to synchronous user input.
-
-    ## Key Benefits
-
-    -   **Synchronous Creation**: Allows for the immediate creation of child datastores without waiting for asynchronous operations.
-    -   **Strong Typing**: Ensures type safety and better developer experience by leveraging TypeScript's type system.
-
-    ## Use Cases
-
-    ### Example 1: Creating a Child Datastore
-
-    In this example, we demonstrate how to support creating a child datastore synchronously from a parent datastore.
-
-    ```typescript
-    /**
-     * This is the parent DataObject, which is also a datastore. It has a
-     * synchronous method to create child datastores, which could be called
-     * in response to synchronous user input, like a key press.
-     */
-    class ParentDataObject extends DataObject {
-    	get ParentDataObject() {
-    		return this;
-    	}
-    	protected override async initializingFirstTime(): Promise<void> {
-    		// create synchronously during initialization
-    		this.createChild("parentCreation");
-    	}
-
-    	createChild(name: string): ChildDataStore {
-    		assert(
-    			this.context.createChildDataStore !== undefined,
-    			"this.context.createChildDataStore",
-    		);
-    		// creates a detached context with a factory who's package path is the same
-    		// as the current datastore, but with another copy of its own type.
-    		const { entrypoint } = this.context.createChildDataStore(
-    			ChildDataStoreFactory.instance,
-    		);
-    		const dir = this.root.createSubDirectory("children");
-    		dir.set(name, entrypoint.handle);
-    		entrypoint.setProperty("childValue", name);
-
-    		return entrypoint;
-    	}
-
-    	getChild(name: string): IFluidHandle<ChildDataStore> | undefined {
-    		const dir = this.root.getSubDirectory("children");
-    		return dir?.get<IFluidHandle<ChildDataStore>>(name);
-    	}
-    }
-    ```
-
-    For a complete example see the follow test:
-    https://github.com/microsoft/FluidFramework/blob/main/packages/test/local-server-tests/src/test/synchronousDataStoreCreation.spec.ts
-
 ## 2.5.0
 
 ### Minor Changes

diff --git a/packages/runtime/runtime-definitions/CHANGELOG.md b/packages/runtime/runtime-definitions/CHANGELOG.md
@@ -27,73 +27,6 @@
     -   Alternatives to calling `IDeltaManager.inbound.pause`, `IDeltaManager.outbound.pause` for `IContainer` disconnect use `IContainer.disconnect`.
     -   Alternatives to calling `IDeltaManager.inbound.resume`, `IDeltaManager.outbound.resume` for `IContainer` reconnect use `IContainer.connect`.
 
--   Enable Synchronous Child Datastore Creation ([#22962](https://github.com/microsoft/FluidFramework/pull/22962)) [67b5e4dca8](https://github.com/microsoft/FluidFramework/commit/67b5e4dca8ae7ae2b2878ecb289e08624f467129)
-
-    ## Overview
-
-    This feature introduces a new pattern for creating datastores synchronously within the Fluid Framework. It allows for the synchronous creation of a child datastore from an existing datastore, provided that the child datastore is available synchronously via the existing datastore's registry and that the child's factory supports synchronous creation. This method also ensures strong typing for the consumer.
-
-    In this context, "child" refers specifically to the organization of factories and registries, not to any hierarchical or hosting relationship between datastores. The parent datastore does not control the runtime behaviors of the child datastore beyond its creation.
-
-    The synchronous creation of child datastores enhances the flexibility of datastore management within the Fluid Framework. It ensures type safety and provides a different way to manage datastores within a container. However, it is important to consider the overhead associated with datastores, as they are stored, summarized, garbage collected, loaded, and referenced independently. This overhead should be justified by the scenario's requirements.
-
-    Datastores offer increased capabilities, such as the ability to reference them via handles, allowing multiple references to exist and enabling those references to be moved, swapped, or changed. Additionally, datastores are garbage collected after becoming unreferenced, which can simplify final cleanup across clients. This is in contrast to subdirectories in a shared directory, which do not have native capabilities for referencing or garbage collection but are very low overhead to create.
-
-    Synchronous creation relies on both the factory and the datastore to support it. This means that asynchronous operations, such as resolving handles, some browser API calls, consensus-based operations, or other asynchronous tasks, cannot be performed during the creation flow. Therefore, synchronous child datastore creation is best limited to scenarios where the existing asynchronous process cannot be used, such as when a new datastore must be created in direct response to synchronous user input.
-
-    ## Key Benefits
-
-    -   **Synchronous Creation**: Allows for the immediate creation of child datastores without waiting for asynchronous operations.
-    -   **Strong Typing**: Ensures type safety and better developer experience by leveraging TypeScript's type system.
-
-    ## Use Cases
-
-    ### Example 1: Creating a Child Datastore
-
-    In this example, we demonstrate how to support creating a child datastore synchronously from a parent datastore.
-
-    ```typescript
-    /**
-     * This is the parent DataObject, which is also a datastore. It has a
-     * synchronous method to create child datastores, which could be called
-     * in response to synchronous user input, like a key press.
-     */
-    class ParentDataObject extends DataObject {
-    	get ParentDataObject() {
-    		return this;
-    	}
-    	protected override async initializingFirstTime(): Promise<void> {
-    		// create synchronously during initialization
-    		this.createChild("parentCreation");
-    	}
-
-    	createChild(name: string): ChildDataStore {
-    		assert(
-    			this.context.createChildDataStore !== undefined,
-    			"this.context.createChildDataStore",
-    		);
-    		// creates a detached context with a factory who's package path is the same
-    		// as the current datastore, but with another copy of its own type.
-    		const { entrypoint } = this.context.createChildDataStore(
-    			ChildDataStoreFactory.instance,
-    		);
-    		const dir = this.root.createSubDirectory("children");
-    		dir.set(name, entrypoint.handle);
-    		entrypoint.setProperty("childValue", name);
-
-    		return entrypoint;
-    	}
-
-    	getChild(name: string): IFluidHandle<ChildDataStore> | undefined {
-    		const dir = this.root.getSubDirectory("children");
-    		return dir?.get<IFluidHandle<ChildDataStore>>(name);
-    	}
-    }
-    ```
-
-    For a complete example see the follow test:
-    https://github.com/microsoft/FluidFramework/blob/main/packages/test/local-server-tests/src/test/synchronousDataStoreCreation.spec.ts
-
 ## 2.5.0
 
 ### Minor Changes