Why is the XDT dependency pinned to 3.1.0 in release/5.0.1xx?

[dagood]

sdk/eng/Version.Details.xml

Lines 172 to 175 in 2b94421

	<Dependency Name="Microsoft.Web.Xdt" Version="3.1.0" Pinned="true">
	<Uri>https://github.com/aspnet/xdt</Uri>
	<Sha>c01a538851a8ab1a1fbeb2e6243f391fff7587b4</Sha>
	</Dependency>

https://github.com/dotnet/sdk/blob/release/5.0.1xx/eng/Version.Details.xml
https://github.com/dotnet/sdk/blob/master/eng/Version.Details.xml (also/still)

This is a problem for arcade-powered source-build: we'll need recent builds to flow that incorporate the source-build changes, so that intermediate nupkgs are available.

@vijayrkn, is this something you're aware of on the XDT side?

@sfoslund, on the SDK side?

This seems to have happened in #11914 (/cc @mmitche @wli3)

[vijayrkn]

@dagood - The xdt library is very stable and we don't have much updates happening on the xdt side. Also this library is shipped on the VS side as well.

That is the reason it is pinned at the version shipped in VS so that both .NET Core and VS will share the same version.

[dagood]

Not being able to update to a new official build is a problem for arcade-powered source-build, but it sounds like it might not be unique to XDT, and not something that we can force to update because of source-build.

I think the simplest way to handle this is to keep building a source-build-specific XDT ourselves for now. We can treat it the same as a few packages that aren't maintained by Microsoft (Newtonsoft.Json, Mono.Cecil) until dotnet/sdk updates to a version of XDT that includes arcade-powered source-build. The transition won't be seamless, but it should be easy.

(The reason that approach doesn't work for most repos is their versions churn rapidly, but that concern is mitigated here because XDT won't update.)

@dseefeld @crummel @dleeapho does that sound ok as the plan when we hit this library stability issue?

---

There are other more complex approaches I don't think we should do:

1. Add a branch to dotnet/xdt that forks from its 3.1.0 commit, and use that branch's outputs as the dependency when source-building dotnet/sdk. Seems tricky to set up that "split" dependency right--extra work for something temporary.
2. We could also set up source-build to seamlessly build the repo from source code if no intermediate nupkg is available, but this is again some mostly throwaway infra that we should avoid implementing for now.

[dseefeld]

@dagood This sounds right to me. Just to be clear, this is an issue with XDT because they're not onboarded to arcade-powered source-build. If a repo that is onboarded gets pinned to a specific version, it will be seamless, because source-build will have built the intermediate package for that version and it will always be available.

[mmitche]

This got pinned a long time ago: dotnet/websdk@36c1b74

@vijayrkn May know why

[dagood]

I think this is answered fine above (#13214 (comment)), thanks--closing.