Consider shipping Microsoft.Windows.Compatibility with every servicing release

[ericstj]

This package itself contains no code or assemblies, so the cost/risk of churning it is minimal.

This package is the shipping vehicle for many of our compatibility packages. Many get these other packages by merely referencing the Microsoft.Windows.Compatibility package. When we update packages referenced by Microsoft.Windows.Compatibility without updating it, it makes it harder for customers to get updates. We could decide to ship it only when one of its dependencies ship (eg: by enforcing this with a validation target in the build) or always ship it.

Doing this will help some customers, though it's not a general solution to the problem. One cannot expect every dependency to update in order to deliver package updates to their dependency graph. So while fixing this might help in many cases - it doesn't help all and a healthy repository will need to have a story for updating other transitive dependencies (like Central package management with transitive pinning)

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This package itself contains no code or assemblies, so the cost/risk of churning it is minimal.

This package is, however, the shipping vehicle for many of our compatibility packages. Many get these other packages by merely referencing the Microsoft.Windows.Compatibility package. When we update packages referenced by Microsoft.Windows.Compatibility without updating it, it makes it harder for customers to get updates. We could decide to ship it only when one of its dependencies ship (eg: by enforcing this with a validation target in the build) or always ship it.

Doing this will help some customers, though it's not a general solution to the problem. One cannot expect every dependency to update in order to deliver package updates to their dependency graph. So while fixing this might help in many cases - it doesn't help all and a healthy repository will need to have a story for updating other transitive dependencies (like Central package management with transitive pinning)

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[carlossanlop]

I vote we always ship a new package version, that will save us from future headaches.
I also vote (as we discussed via chat) to set up a Maestro subscription of the packages M.W.C depends on so they get bumped automatically in 6.0 when a new version is available, like System.Data.SqlClient.

[ViktorHofer]

I also vote (as we discussed via chat) to set up a Maestro subscription of the packages M.W.C depends on so they get bumped automatically in 6.0 when a new version is available, like System.Data.SqlClient.

I don't think that we want or can create subscriptions between releases. Microsoft.Windows.Compatibility in release/6.0 would depend on System.Data.SqlClient from release/3.1. cc @mmitche

[ericstj]

That's what it would depend on today, but maybe in the future SqlClient would publish to a "dotnet-libraries" channel. I don't think we need to block this on the possibility of subscriptions for out-of-repo dependencies. We can treat the issue of subscriptions here as separate. Does anyone object to always building and shipping this meta-package?

[carlossanlop]

I'm in favor. Here is the 6.0 branding PR - I'm bumping the package version: https://github.com/dotnet/runtime/pull/77750/files#r1012323084

[ViktorHofer]

We could decide to ship it only when one of its dependencies ship (eg: by enforcing this with a #66106 in the build) or always ship it.

Honestly, I would prefer to only ship M.W.Compatibility when one of its dependencies changed. Otherwise, customers would see a package update notification every month which would create noise in the ecosystem. Is it hard to implement such a system or would we need to rely on hand work?

[ericstj]

I think I shared a sample that would do this through a validation target. Initially that was proposed as a global target, but we could make it opt-in and have M.W.C opt into it.

We'd still require the developer to flip the bit to turn it on and increment the version. If we wanted that to be automatic, we could use that target to flip the bit and then just calculate the version (eg same as the product's servicing version).

[ViktorHofer]

Both ideas sound good to me.

and then just calculate the version (eg same as the product's servicing version).

If we would start introducing holes in the package versions, i.e. from 7.0.0 to 7.0.3 without a 7.0.1 and 7.0.2, then I would prefer to do it consistently for all packages, not just for M.W.Compatibility.

we could use that target

As long as that works with static graph restore/build great.

[ericstj]

It could be problematic to calculate version by running targets. As you mentioned - restore likes to record the version of a project. There's also the case of an update that's not the result of a local package servicing (eg: WCF, SqlClient) which wouldn't be detected by the sample I shared. Probably getting it right automatically is a lot of complexity for little benefit.

I'm inclined to just go down the always build route. Compute ServicingVersion as $([MSBuild]::Subtract($(PatchVersion), 11)) - or whatever makes it continuous.

[ViktorHofer]

I'm inclined to just go down the always build route. Compute ServicingVersion as $([MSBuild]::Subtract($(PatchVersion), 11)) - or whatever makes it continuous.

I want to express my concerns with that. That will effectively put the burden on our customers instead of us and will result in monthly package updates even though nothing changed. I think we should aim high and find a better solution that avoids the burden on the customer's side.

It could be problematic to calculate version by running targets

My suggestion above was to just use the $(PatchVersion) and be fine with package version holes. That's what other repositories in our stack already do. We wouldn't need a target for that.

There's also the case of an update that's not the result of a local package servicing (eg: WCF, SqlClient) which wouldn't be detected by the sample I shared.

While that's true, we can cover externals with tools like dependabot or others. With the validation target that you shared above, we would be able to handle the majority (90+%) of our dependencies.