Remove the support for variants and telemetry from the .NET feature flag schema

[zhenlan]

Open a tracking issue following the discussion: #393 (comment)

We should do this before v4.0.0 turns stable.

[rossgrambo]

Deprecating the .NET FF schema is not as straightforward as that discussion makes it sound. For the FM library, it can make the switch, but the provider today only returns the Dotnet schema and can't make the switch as easily.

This change means the provider needs to switch to snake_case, which means newer versions of the provider will not work with old versions of FeatureManagement. Unless the provider can do some version determination but that doesn't sound great.

cc; Jimmy Campbell (@jimmyca15) Amer Jusupovic (@amerjusupovic)

[jimmyca15]

There is a way to support it that I thought of. Throwing it out there.

Flags with variants are put into IConfiguration with the Microsoft FF schema. Flags without variants are put into IConfiguration with the .NET FF schema.

I.e.

{
    "FeatureManagement": {
        "Beta": true
    },
    "feature_management": {
        "feature_flags": [
            {
                "id": "Gamma",
                "Variants": [
                    ...
                ]
            }
        ]
    }
}

The .NET feature management library would need to respect both sections being defined.

[rossgrambo]

We could go that route, but I'm concerned someone would add a variant to an existing flag, and now suddenly that flag disappears. I suppose the UI doesn't support adding variants- but it doesn't sound ideal.

[zhenlan]

Nothing disappears. You just need the newer version FM library, but you need the new version FM library for variant anyway.

[rossgrambo]

Without making code changes, if a user has <V4 of FM and they use portal to edit the flag and add a variant, refresh would make the flag disappear in their running application. (If they had latest provider)

[zhenlan]

You added variant to an existing feature flag, but you didn't update your application to use the FM library that supports variant. What's your expected outcome for this scenario?

[rossgrambo]

The current functionality, which is their flag continues to work as a flag without variants until they update FM to read the "Variants" & other fields. This update lets GetVariant work and lets the StatusOverride work.

[jimmyca15]

Without making code changes, if a customer has <V4 of FM and they use portal to edit the flag and add a variant, refresh would make the flag disappear in their running application. (If they had latest provider)

We don't allow updating an existing flag to add variants though.

[rossgrambo]

We don't allow updating an existing flag to add variants though.

You're right it's not possible today in the UI via normal edit. But there's other ways to edit & the edit flow may change.

[rossgrambo]

This would be the first time the division between a variant flag and non variant flag is more than just a portal UI decision.

[zhenlan]

It's an unsupported scenario. The result is non-deterministic if a customer feeds a variant feature flag to an old FM library that doesn't support variant. In the eyes of the old FM library, the variant feature flag is "invalid". A customer shouldn't expect it returns anything meaningful (even if it doesn't fail right away).

[rossgrambo]

Regardless of my edit concern- If we go with the variant separation plan, I think we're kicking the can down the road for deprecating the old schema.

I'd rather commit fully to the new schema and accept the breaking change now. As far as I understand, the provider will have to do it eventually.