Cleanup of nuget packages for v2 branch and preview v3

[thompson-tomo]

Is your feature request related to a problem? Please describe.

Currently when looking at the nuget packages for steeltoe there is a lot of packages and for a user there is no clear guidance as to which one's are still supported and which one's have simply changed name

Describe the solution you'd like

I would like a spring clean of the nuget package so that it is clear to developers which one's to use etc.

Describe alternatives you've considered

Leave the packages as they are

Identified packages

The list of packages i have identified are as follows:

Nuget Package	Action	Transferred to
Steeltoe.CircuitBreaker.HystrixAutofac	Deprecate	Steeltoe.CircuitBreaker.HystrixCore
Steeltoe.CircuitBreaker.Hystrix.MetricsStreamAutofac	Deprecate	Steeltoe.CircuitBreaker.Hystrix.MetricsStreamCore
Steeltoe.CloudFoundry.ConnectorAutofac	Deprecate	Steeltoe.Connector.ConnectorCore
Steeltoe.CloudFoundry.ConnectorBase	Unlist
Steeltoe.CloudFoundry.ConnectorCore	Unlist
Steeltoe.CloudFoundry.Connector.EFCore	Unlist
Steeltoe.CloudFoundry.Connector.EF6Autofac	Deprecate	Steeltoe.Connector.EF6Core
Steeltoe.CloudFoundry.Connector.EF6Core	Unlist
Steeltoe.Common.Autofac	Deprecate	Steeltoe.Common Maybe??
Steeltoe.Discovery.ClientAutofac	Deprecate	Steeltoe.Discovery.ClientCore
Steeltoe.Discovery.ConsulBase	Unlist
Steeltoe.Discovery.EurekaBase	Unlist
Steeltoe.Extensions.Logging.SerilogDynamicLogger	Deprecate	Steeltoe.Extensions.Logging.DynamicSerilogCore
Steeltoe.Extensions.Configuration.ConfigServerAutofac	Deprecate	Steeltoe.Extensions.Configuration.ConfigServerCore
Steeltoe.Extensions.Configuration.CloudFoundryAutofac	Deprecate	Steeltoe.Extensions.Configuration.CloudFoundryCore
Steeltoe.Management.EndpointOwinAutofac	Deprecate	Steeltoe.Management.EndpointCore
Steeltoe.Management.EndpointOwin	Deprecate	Steeltoe.Management.EndpointCore
Steeltoe.Management.ExporterBase	Deprecate
Steeltoe.Management.ExporterCore	Deprecate
Steeltoe.Management.OpenCensus	Deprecate	Steeltoe.Management.TracingCore
Steeltoe.Management.OpenCensus.Abstractions	Deprecate	Steeltoe.Management.TracingBase
Steeltoe.Management.OpenCensus.ZipkinExporter	Deprecate
Steeltoe.Management.OpenCensusBase	Unlist
Steeltoe.Security.Authentication.CloudFoundryWcf	Deprecate	Steeltoe.Security.Authentication.CloudFoundryCore
Steeltoe.Security.Authentication.CloudFoundryOwin	Deprecate	Steeltoe.Security.Authentication.CloudFoundryCore

Additional Context

https://learn.microsoft.com/en-us/nuget/nuget-org/deprecate-packages

[TimHess]

All versions of all packages except those versioned 2.5.5, 3.2.8 and 4.0.0-beta1 are now unlisted

[thompson-tomo]

Hi @TimHess is there a particular reason why you went and unlisted the old versions rather than just deprecating them as that way a user can see the past popularity of the package especially for thr stable release. I Don't have a concern about unlisting preview packages this is more about the stable versions.

[TimHess]

Hi @TimHess is there a particular reason why you went and unlisted the old versions rather than just deprecating them as that way a user can see the past popularity of the package especially for thr stable release. I Don't have a concern about unlisting preview packages this is more about the stable versions.

@thompson-tomo, unlisting is something that can be done (or reversed) in bulk and fits with the spring cleaning idea proposed in this issue. I can reverse it if it seems like we're now hiding useful info.

I was planning to wait until we have GA release of 4.0 before doing any new deprecation changes (which is a manual operation that can only be completed through the nuget.org web UI)

[thompson-tomo]

Thanks Tim. My preference is to deprecate via UI wherever possible the stable releases and only unlist packages which were pre-release. That way we can still see the history of the libraries and when doing a search you are only seeing stable versions or v4 pre-release packages. Note this issue is focussed on cases of package rename etc.

[bart-vmware]

@TimHess
I agree that unlisting released versions is a bad idea. Users depend on them today, and although the versions can still be downloaded, hiding them from the UI is confusing. Please revert the unlisting of older versions, including pre-release versions.

@thompson-tomo
We don't take the deprecation of packages lightly. While https://github.com/SteeltoeOSS/Steeltoe/wiki/Steeltoe-Support-Versions states that 3.x and 2.x are out of support, we can't realistically deprecate them today because there is no alternative yet. We have reason to believe both 3.x and 2.x are still widely being used. Furthermore, 2.x is the last version that supports .NET Framework, and we might need to revive efforts there if an important customer requires so.

Also, the NuGet search is a way to browse history, not the primary place to select which packages to use. Users typically need a feature (documented at https://docs.steeltoe.io/api/v4/welcome/) and then install the required packages indicated in the docs. When users do search via NuGet, the date of the last release should indicate whether the package is a good choice for new development. While we'd like everyone to jump on the latest version, the reality is that most enterprise users won't, and they are important to us. Therefore, we try to tease users into upgrading by advocating improvements, yet we are hesitant in telling them older packages are abandoned and must not be used.

[TimHess]

The packages that I unlisted should all be back except for 3.0.0-m1 through 3.0.0-m3, which as I recall had some confusing name changes. If that proves to be an issue in the future, we can look at relisting at least some of those as well

[thompson-tomo]

Thanks Tim/Bart. I can understand your view about discontinuation, perhaps the discontinuation of packages should instead focus on just the packages which were never brought across to newer major versions ie v3 or v4 due to there being alternatives. Some examples which spring to mind would be Hystrix, OpenCensus, messaging/streams, kubernetes et

[bart-vmware]

I'm afraid we can't do that. Our current thinking is that we'll support v3 for another year after the v4 release. That support includes the features that no longer exist in the latest version. This is similar to binary serialization, which was removed from .NET 9 but is still fully supported on .NET Framework.

A deprecated (or vulnerable) package version may trigger deployment failures, depending on company-wide policies, that developers have no control over. We don't want that to happen for packages that are still supported (but discouraged for new development).

Still, we'd like to notify developers that new developments with v2/v3 are not recommended. I think the best way to accomplish that is by publishing v4 versions that don't compile (as suggested here). This way, developers are notified a new version exists (which they can choose to ignore). If not ignored and the version is updated, our message appears. Then it's easy to roll back the version update, while still being able to consume newer 3.x minor/patch versions as we release them.