-
Notifications
You must be signed in to change notification settings - Fork 73
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
Conversation
### Additional Changes | ||
|
||
#### BlazorServerApp | ||
|
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.
That's not part of the released packages.
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.
These release notes are limited exclusively to the functionality of the released packages.
|
||
#### Net8 build target | ||
|
||
Net8 was added as a build target. |
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.
This should be presented as a feature - we added support for .NET 8.
(Reminder of the release notes guidelines - talk about the feature in customer perspective, not how we implement it.)
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.
Hard to find the correct thing to say- seeing as the only change was adding it was a build target- which means we're less likely to break Net8, but there's no immediate customer benefit.
I went with:
Net8 support
Added support for Net8 applications by adding Net8 as a build target.
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.
microsoft/FeatureManagement-Dotnet#365
What this PR did was to have our test suites also build for .NET 8.0.
Maybe we should not mention this in the release note, since the user will not notice this change.
This is blocked by microsoft/FeatureManagement-Dotnet#388 for now. *Edit- no longer blocked |
@zhenlan @jimmyca15 & @zhiyuanliang-ms, this has been updated to follow release notes guidelines. |
### Enchancements | ||
|
||
* 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). | ||
* 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)) |
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.
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?
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.
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.
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.
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.)
|
||
### Enchancements | ||
|
||
* 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). |
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.
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.
|
||
* 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). | ||
* 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)) | ||
* Added support for Net8 applications by adding Net8 as a build target. ([#364](https://github.com/microsoft/FeatureManagement-Dotnet/issues/364)) |
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.
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.
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.
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 ..."?
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.
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 Microsoft.FeatureManagement.AspNetCore
package.
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.
That works for me- maybe a small tweak to be:
Added support for .NET 8 target framework to the Microsoft.FeatureManagement.AspNetCore
package.
@@ -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 |
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.
Enhancements
No description provided.