For contrib repositories, we should remove contrib and be consistent

[askpt]

Description

I am proposing that we remove Contrib from the package names and namespaces. We should do it sooner due to some essential features (ofrep, etc) getting 1.0.

We should use:

• OpenFeature.Hooks.HookA
• OpenFeature.Providers.ProviderA

Repositories

• dotnet: has contrib in the package name and the namespace. Also, we are not 100% consistent with the name.
• Java: has contrib in the package name and the namespace.
• rust: seems not to use contrib at all.
• Python: has contrib in the package name and the namespace.
• go: seems not to use contrib at all.
• JavaScript: seems not to use contrib at all.
• elixir: seems not to use contrib at all.
• Ruby: seems not to use contrib at all.
• PHP: seems not to use contrib at all.

Why?

As mentioned before, I see two significant advantages:

• Allows us to easily move features like ofrep or multi-provider without difficulty between sdk and contrib.
• It doesn't have a lot of value.

Related

open-feature/dotnet-sdk-contrib#154

[beeme1mr]

I'm in favor of consistency as long as the old packages are deprecated and we have a clear migration guide for users. The main value of including "contrib" is to convey that there's a difference between a community-maintained provider and an official provider. It's difficult to tell if that's a compelling enough reason or if interoperability and consistency are more important.

By the way, we did have a recommended naming convention, but obviously we didn't do a great job following it. 😆

[toddbaert]

@askpt I think we should do this. IMO, we should:

• add a README to our packages in nuget (for some reason, we don't have them, even though it's possible); we are just showing the package description: https://www.nuget.org/packages/OpenFeature.Contrib.Providers.Flagd
• publish a "final version" of each package with a README that says it's deprecated, and point to the location where the new one will be
• publish the new package, probably with the same version number, and deprecate the old in nuget, mentioning the new one as the alternate,

What do you think?

[askpt]

I agree with points 1 and 2.
For point 3, I think it will be a challenge. I would prefer to do a minor version bump (where we clean-up the readme and so on).
https://www.nuget.org/packages/OpenTelemetry.Contrib.Instrumentation.AWS <- This is an example of a deprecated package.

[toddbaert]

That works for me!

The important part for me is users see the deprecation as clearly as possible, and ideally know where to go for the new one.

[askpt]

I will create a GitHub issue structure for flagd (which can be replicated for other providers and languages).

[askpt]

I created the initial structure here for flagd: open-feature/dotnet-sdk-contrib#423
And we will use this open-feature/dotnet-sdk-contrib#195 as a to-do task for NuGet admin work.