CoreCLR packages are not servicing ready

[ericstj]

Recently identified in #111444

All packages under https://github.com/dotnet/runtime/tree/7bb850f5f660e815aefe5a0937c6c29635820af8/src/coreclr/.nuget are not set up to ship in servicing.

If they're meant to be enabled/disabled incrementally then a process around versioning and enabling needs to be documented and followed for servicing changes.

If they're meant to always ship, then changes to the build need to be made to enable them and consumers need to be set up to react to those regular changes.

[dotnet-policy-service]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

[ericstj]

This may apply for packages other than those in coreclr/.nuget. Those are just the ones we noticed. It makes sense to do an audit of all packages maintained by runtime to see if they have a process for servicing. That way you can discover gaps before the day they need to be serviced.

[hoyosjs]

@ericstj - some of them are meant to be published every time. What stopped producing them/marking them as shipping?

[ericstj]

They've always been that way if you look at the publishing history, for example https://www.nuget.org/packages/runtime.win-x64.Microsoft.NETCore.ILDAsm

I suspect if you want them to build with every release you might need to determine if that would have any side-effects - make sure the packages are setup to flow / version correctly / etc.

[JulieLeeMSFT]

@amanasifkhalid, PTAL.
CC @jkoritzinsky.

[amanasifkhalid]

some of them are meant to be published every time. What stopped producing them/marking them as shipping?

Are there any that shouldn't be shipped for servicing?

I suspect if you want them to build with every release you might need to determine if that would have any side-effects - make sure the packages are setup to flow / version correctly / etc.

Aside from kicking off an official build, is there anything else we can/should do to verify these packages can be shipped before the next servicing release?

[jkotas]

Are there any that shouldn't be shipped for servicing?

The ones that ship as part of GA should be shipped as servicing too.

Number of packages in this directory are non shipping, for example, https://github.com/dotnet/runtime/blob/main/src/coreclr/.nuget/ILCompiler.Reflection.ReadyToRun.Experimental/ILCompiler.Reflection.ReadyToRun.Experimental.pkgproj#L5 . This package does not ship as part of GA and it should not be shipped during serving either.

[amanasifkhalid]

The ones that ship as part of GA should be shipped as servicing too.

Thanks -- I suppose we should start by removing the catch-all rule here, and let the package configs handle themselves. Would getting a successful official build with this change on top of a copy of the release/9.0-staging branch be a good starting point for verifying this change? Or do servicing builds use a different process?

[JulieLeeMSFT]

We think there is no different process for servicing builds.
CC @carlossanlop.