-
Notifications
You must be signed in to change notification settings - Fork 75
Release notes for 4.0.0-preview2 #886
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
Changes from all commits
e01c3f4
55c0c64
d50d9de
27e926b
b3c99aa
cfdc69f
84ccf78
2f1f4d4
63148fb
0b2fbc0
1609034
12bc72d
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,18 @@ | |
| # Microsoft.FeatureManagement.AspNetCore | ||
| [Source code ][source_code_web] | [Package (NuGet)][package_web] | [Samples][samples_web] | [Product documentation][docs] | ||
|
|
||
| ## 4.0.0-preview2 - March 7, 2024 | ||
|
|
||
| ### Enchancements | ||
|
Member
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. Enhancements |
||
|
|
||
| * Use flags to enable different service implementations in dependency injection. ([#39](https://github.com/microsoft/FeatureManagement-Dotnet/issues/39)). See more details [here](https://github.com/microsoft/FeatureManagement-Dotnet/tree/preview?tab=readme-ov-file#variants-in-dependency-injection). | ||
|
Member
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. It feels like we are shifting from providing too much information to providing too little information (or being vague) now. We still want the release notes to be useful to customers. It took real work to explain big features with one or two sentences. I gave it a shot. Please feel free to update. Added support for variant feature flag-based service provider in dependency injection. It allows different service implementations to be injected automatically for different targeted audiences based on their variant assignment. |
||
| * Additional mechanisms to track targeting within telemetry to improve the connection between published events and metrics. ([#409](https://github.com/microsoft/FeatureManagement-Dotnet/issues/409)) | ||
|
Member
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. We don't want to make release notes like a document, but it doesn't mean we don't want customers to understand our release notes. The changes in the linked PRs are not even part of this package. We mentioned nothing about the new packages. Can we explain how the feature you did can benefit customers?
Member
Author
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. This concept is a little in the weeds to dig into. The linked issue links to a PR that explains it microsoft/FeatureManagement-Dotnet#350 (comment). The customer does not receive much benefit from this- it was a change on how we connect dots which were already connectable. But this is a more stable version. Do you prefer something like: Introduced middleware and a telemetry property for Targeting Id, which can be used to connect published evaluation events to other emitted telemetry from a given target.
Member
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. We released two new packages and found "The customer does not receive much benefit from this". We must be missing something :) (We should create separate file(s) for the release notes.) |
||
| * Added support for Net8 applications by adding Net8 as a build target. ([#364](https://github.com/microsoft/FeatureManagement-Dotnet/issues/364)) | ||
|
Member
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. It's not that we didn't support .NET 8 applications before this change. By adding .NET 8 to the targeting framework, we make sure this library uses .NET 8 libraries/APIs when users build a .NET 8 application.
Member
Author
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. Based it off your previous comment: #886 (comment) We added net8 as a build target which means we will run tests against it. We did also update the external libraries from 7.0 to 8.0. The only customer facing change here is: "we're less likely to break a .net8 app now". I'd argue that's "adding support ...", but as you said that makes it sound like it wasn't supported at all before. What about just "Added better support ..."?
Member
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. Don't quote on me. I wasn't using release-notes ready language in all comments :) How about this? Added support for .NET 8 targeting framework to the
Member
Author
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. That works for me- maybe a small tweak to be: Added support for .NET 8 target framework to the |
||
|
|
||
| ### Breaking Changes | ||
|
|
||
| No breaking changes in this release. | ||
|
|
||
| ## 3.2.0 - February 29, 2024 | ||
|
|
||
| ### Enhancements | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.