FeatureManagement 4.0.0-preview2 release notes update

[rossgrambo]

Fixes misspelling and updates a bullet of the release notes.

[rossgrambo]

Split files and updated based off feedback on previous PR #886

[rossgrambo]

I don't recall where we landed on what the github release notes should look like now that these are split. Here's the current release notes: https://github.com/microsoft/FeatureManagement-Dotnet/releases

I suppose we can connect all of the changes from all of the files like this:

4.0.0-preview2

Microsoft.FeatureManagement Updates

Enhancements

• 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. (#39). See more details here.
• Added TargetingContext to evaluation events. This allows events to accuratly represent what the targeting context was at the time of feature evaluation. (#409)

Microsoft.FeatureManagement.AspNetCore

Enhancements

• Added TargetingHttpContextMiddleware, which ensures TargetingContext is available for syncronous functions, like TargetingTelemetryInitializer in the Microsoft.FeatureManagement.Telemetry.ApplicationInsights.AspNetCore package. (#409)
• Added support for .NET 8 target framework. (#364)

Microsoft.FeatureManagement.Telemetry.ApplicationInsights

Enhancements

• Added a property to published telemetry named TargetingId. This is a more reliable way to connect evaluated feature flags to other telemetry events for a given target. (#409)

Microsoft.FeatureManagement.Telemetry.ApplicationInsights.AspNetCore

Enhancements

• Added TargetingTelemetryInitializer, which appends targeting information to all outgoing telemetry to Application Insights. (#409)

[zhenlan]

I hope this explains why a change can benefit a customer.

Added a TargetingId property to the feature evaluation events sent to Application Insights. The TargetingId is the identifier of a targeted user during feature evaluation. This new property allows you to correlate feature evaluation events with other telemetry data your application sends to Application Insights, as long as they share the same TargetingId.

[rossgrambo]

That can work- but the nuance to me is

allows you to correlate feature evaluation events with other telemetry data your application sends to Application Insights, as long as they share the same TargetingId.

Correlating events was already possible in the previous version using one of Application Insights user id fields.

I think this change is more about decoupling the id from Application Insights / not locking ourselves to users / ensuring we emit whatever the value of "Targeting.UserId" was instead of relying on an ambient field that might not correlate with the Targeting value.

[rossgrambo]

Maybe we could call out that it's explicitly the targeting information from evaluation. Like:

based on the targeting information from feature evaluation.

Which says that it's no longer some ambient field- but the actual targeting information used during evaluation.

[zhenlan]

in the previous version using one of Application Insights user id fields.

Sounds like a breaking change.

[rossgrambo]

Shouldn't be, correlating via user id is still possible.

[zhenlan]

Correlating events was already possible in the previous version using one of Application Insights user id fields.

If we did this (add userid to "one of Application Insights user id fields") before and not anymore in the new release. It sounds like a breaking change to me.

[rossgrambo]

Yeah that would be, but we don't add it. App Insights package automatically generates and adds user id. In our early examples, we were adding AuthenticatedUserId, but it was added/managed in the customer code and not in the library. That approach would still work today.

[zhenlan]

we were adding AuthenticatedUserId, but it was added/managed in the customer code and not in the library

Got it. This means we didn't provide a solution out of the box before and now we do. Customers must do it in their application code before this release. Yes, correlating via user id was already possible, but for the sake of the argument :), the whole feature management was possible by user code completely. The release notes are about what we provide out-of-the box regardless of whether something was possible or not by the user code.

I think this change is more about decoupling the id from Application Insights / not locking ourselves to users...

This is true from our perspective. From the customer perspective, it's all about correlating events. How to do it? It's an implementation detail.

[rossgrambo]

True, but just to note again. Application Insights generates UserId out-of-the-box which can be used to correlate without custom customer code. Its limitation is hard refreshing or switching apps wouldn't track the user. Our example used AuthenticatedUserId because we wanted to get around that. We could say TargetingId is the new out-of-the-box way to get around it.

A customer today who wants to run experiments with anonymous data from users would likely still use the UserId field (or manually set TargetingId to the value of UserId).

[rossgrambo]

Updated to your original suggestion:

Added a TargetingId property to the feature evaluation events sent to Application Insights. The TargetingId is the identifier of a targeted user during feature evaluation. This new property allows you to correlate feature evaluation events with other telemetry data your application sends to Application Insights, as long as they share the same TargetingId.

[zhenlan]

How strongly do we feel the necessity of adding this no-breaking-change disclaimer? We don't do this in other release notes. Even if we put this, there is no guarantee of no breaking changes. There are just no known breaking changes.

[rossgrambo]

I'll remove it for now- seeing as the guidelines don't suggest we have it.