fix!: rename namespace, add OpenFeature dep

[toddbaert]

This is mostly just renames to prevent an issue @benjiro experienced earlier with the SDK where the OpenFeature namespace collided with the singleton. I've updated the namespaces and dirs to OpenFeatureContrib. It also adds a README.

The other thing I've done is add a PackageRef for the SDK:

  <ItemGroup>
    <PackageReference Include="OpenFeature" Version="$(OpenFeatureVer)">
    </PackageReference>
  </ItemGroup>

I'm not sure if I need to add exclude/include/privateassets attributes... I want the library I'm releasing to use the version the consumer provides, not a transatively resolved version. I'm not sure exactly how to express this.

[toddbaert]

I'm having a difficult time understanding the documentation here: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

Is this right? I've basically used the default PrivateAssets, plus added runtime

The resultant nuspec dependencies element looks like this:

    <dependencies>
      <group targetFramework=".NETFramework4.6.2">
        <dependency id="OpenFeature" version="[0.4.0, 0.5.0)" exclude="Runtime,Build,Analyzers" />
      </group>
      <group targetFramework=".NETStandard2.0">
        <dependency id="OpenFeature" version="[0.4.0, 0.5.0)" exclude="Runtime,Build,Analyzers" />
      </group>
    </dependencies>

[benjiro]

@toddbaert I don't think we need to worry about playing around with asset inclusion, the default behaviour is to include all.

The current versioning will resolve the smallest acceptable version (0.4.0) unless the consumer already has a higher version dependency on OpenFeature which nuget will resolve that version instead (anything less than 0.5.0). We probably want it to automatically take the latest patch version which would be 0.4.* https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges

Hope that makes sense.

[toddbaert]

@toddbaert I don't think we need to worry about playing around with asset inclusion, the default behaviour is to include all.

OK, I've removed the customization of the asset inclusion.

The current versioning will resolve the smallest acceptable version (0.4.0) unless the consumer already has a higher version dependency on OpenFeature which nuget will resolve that version instead (anything less than 0.5.0). We probably want it to automatically take the latest patch version which would be 0.4.* https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges

Hope that makes sense.

It does.

However, if I modify the value of the OpenFeatureVer as you specify:

<OpenFeatureVer>0.4.*</OpenFeatureVer>

Then the resultant nuspec dependency element looks like this:

    <dependencies>
      <group targetFramework=".NETFramework4.6.2">
        <dependency id="OpenFeature" version="0.4.0" />
      </group>
      <group targetFramework=".NETStandard2.0">
        <dependency id="OpenFeature" version="0.4.0" />
      </group>
    </dependencies>

As you can see, it's a specific version... 0.4.0. I think we'd want this to be a range, no?

[benjiro]

Yea ok, seems like nuget doesn't allow it without repackage the project each time a new version is release.

Lets just keep with the version range, if the consumer wants the latest patch version of OpenFeature they will need to take a direct dependency to override the transitive one.

[benjiro]

@toddbaert I don't think we need to worry about playing around with asset inclusion, the default behaviour is to include all.

The current versioning will resolve the smallest acceptable version (0.4.0) unless the consumer already has a higher version dependency on OpenFeature which nuget will resolve that version instead (anything less than 0.5.0). We probably want it to automatically take the latest patch version which would be 0.4.* https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges

Hope that makes sense.

[benjiro]

LGTM 👍🏻

[toddbaert]

@benjiro I know it's a breaking change, and it would be a bit annoying, but what do you think about renaming the OpenFeature singleton to "Api" and changing the namespaces in both the contribs and the SDK to "OpenFeature"?

We certainly don't have to, I'm just trying to make sure we make the optional decision before a 1.0. Let me know your thoughts.

[benjiro]

Yea I think that is a better way to go, I think the Java SDK did something similar from memory.

[toddbaert]

Yea I think that is a better way to go, I think the Java SDK did something similar from memory.

Cool. I can do this but it won't be until later today/tonight.

[benjiro]

@toddbaert check out open-feature/dotnet-sdk#82, im out all day if it needs to be changed go ahead

[toddbaert]

@toddbaert check out open-feature/dotnet-sdk#82, im out all day if it needs to be changed go ahead

Amazing! I just pushed a fix for a formatting issue in your SDK PR. Published now and looks good. I absorbed the 0.5.0 changes here and they look great. I'm much happier with this naming! Thank you again.