-
Notifications
You must be signed in to change notification settings - Fork 73
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
Changes from 2 commits
9d2d682
835036d
62ac7d9
4af54a6
67a9989
dd927ae
68e78be
90b49ba
5b58549
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
|
||
* Exposing FeatureManager and ConfigurationFeatureDefinitionProvider to public. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
For release notes I would expect something more succint like
|
||
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)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
There was a problem hiding this comment.
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?