Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add release note for FeatureManagement 3.1.0 #839

Merged
merged 9 commits into from
Nov 30, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions releaseNotes/Microsoft.Featuremanagement.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,22 @@
# Microsoft.FeatureManagement.AspNetCore
[Source code ][source_code_web] | [Package (NuGet)][package_web] | [Samples][samples_web] | [Product documentation][docs]

## 3.1.0 - November 23, 2023

### Changes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug fixes are changes too. Should this be "Enhancement"? I know this might be copied from the previous one. Can we fix that too?


* Exposing FeatureManager and ConfigurationFeatureDefinitionProvider to public.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release notes aren't documentation, so I would be weary of writing something too long here. If it is a long description and you feel it is needed then I would consider one of the two options:

  • Write the description in the PR that added it and link to the PR (as you have done).
  • Update the readme in the repo.

For release notes I would expect something more succint like

  • FeatureManager and ConfigurationFeatureDefinitionProvider are now public
    • Enables usage of external dependency injection containers
    • Allows usage of feature manager without requiring dependency injection

The `FeatureManager` and `ConfigurationFeatureDefinitionProvider` classes are the core services of the feature management system. In the past, both of them were internal and could only be registered via the AddFeatureManagement() method, which relies on `Microsoft.Extensions.DependencyInjection`. This limitation prevented third-party DI container systems from registering these classes, making them incompatible with the entire feature management system. With this change, all Feature Management services have been made accessible to other DI containers. (Related issues: [#126](https://github.com/microsoft/FeatureManagement-Dotnet/issues/126) [#258](https://github.com/microsoft/FeatureManagement-Dotnet/issues/258))

Additionally, the recommended [way](https://learn.microsoft.com/en-us/aspnet/core/blazor/security/server/interactive-server-side-rendering?view=aspnetcore-7.0#ihttpcontextaccessorhttpcontext-in-razor-components) for accessing `HttpContext` in Blazor is through a scoped context provider service. The singleton `HttpContextAccessor` pattern, while works well in ASP.NET Core, becomes unreliable in Blazor environments. As a result, to use `Targeting` in Blazor, the targeting filter and targeting context accessor should be registered as scoped. (Related issue: [#15](https://github.com/microsoft/FeatureManagement-Dotnet/issues/15) [#258](https://github.com/microsoft/FeatureManagement-Dotnet/issues/258))

* AddScopedFeatureManagement
We have introduced an alternative way `AddScopedFeatureManagement()` to register the feature management system, where the feature manager and all feature filters will be registered as scoped. It ensures that the integration aligns with Blazor's best practices for handling `HttpContext` and enhances the overall ease of use. There is an ongoing PR to demonstrate how to use FeatureManagement in Blazor server app: [#306](https://github.com/microsoft/FeatureManagement-Dotnet/pull/306)

### Bug Fixes
* Preserved the behavior in 2.x.x when passing a configuration section to `AddFeatureManagement(IConfiguration configuration)`. ([#308](https://github.com/microsoft/FeatureManagement-Dotnet/issues/308))
* Preserved the behavior in 2.x.x when there is a contextual filter specified, but there is no appropriate context provided during the feature flag evaluation. ([#313](https://github.com/microsoft/FeatureManagement-Dotnet/issues/313))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed a bug introduced in the previous release where evaluation of a feature flag that references a contextual feature filter may throw an error if the contextual feature filter is not registered or a context is not provided during evaluation.


## 3.0.0 - October 27, 2023

### Breaking Changes
Expand Down