Figure out how source-build will work with CoreFX per-package servicing policy

[dagood]

For each patch release, the Microsoft build creates the specific non-shared-framework packages that have changes to release. #210 tracks building all CoreFX packages in every source-build build, but we risk shipping a different product than the Microsoft build if we just do that:

• Tooling changes or unrelated changes elsewhere in the CoreFX repo could affect the contents of non-shared-framework packages.
• There might be changes checked into CoreFX for some non-shared-framework packages even though their package builds aren't enabled for the upcoming patch release.
  • For example, a bugfix could be checked in pending the next release but determined to be too risky, causing the package to be excluded from the Microsoft build so the bugfix isn't shipped. The code could be left in so it can go through tests and continued development for a future patch release.

If possible, it seems best to emulate the Microsoft release strategy by building each patch release's CoreFX packages and accumulating them over time. These could be separate from (then combined with?) the Runtime/SDK builds. The first open question that comes to mind is: how do we backfill the set of non-shared-framework packages for a new platform?

(Contrast with the shared framework packages. The entire shared framework is rebuilt for every patch release, which is the same thing source-build does. No changes needed there.)

/cc @dseefeld

[chcosta]

Is there a timeline for this? This is blocking issue #970

[dagood]

I'd question that classification--seems more likely to be used as ref only.

I don't think there's a timeline. @dseefeld @crummel @dleeapho for that.

[chcosta]

I'd question that classification--seems more likely to be used as ref only.

Quite possible, and fantastic if true. What leads you to that conclusion?

[dagood]

I'd expect Arcade tasks to compile against the bits, then when MSBuild actually loads the tasks, the SDK's copy of these DLLs would be loaded (which come from the N-1 build). The compile ref DLLs are the oldest possible version for compatibility against a variety of runtimes, and the SDK carries the newest version so improvements/patches are used at runtime.

[chcosta]

That makes sense, I didn't realize these were in the SDK. Thanks Davis

[dagood]

Some ways to reduce risk here and a few thoughts on them:

1. Add safeguards that the new package behaves the same as the old one.
   • It can be a CI check that repo owners are responsible for. For example, a
     test could download the last-released package and check that the contents
     have no meaningful differences. (Ideally byte-for-byte identical with a
     deterministic build.)
     • This can't be done by the build from source itself, because there is no access to
       previously built artifacts.
2. Ensure the current source code hasn't changed since the last release.
   • It's not easy to determine which source code to track, and this doesn't
     account for infrastructure changes such as new Arcade and SDK versions.
   • I don't see this as viable.
3. Have repo maintainers evaluate the potential to break this scenario when
   merging any servicing PRs.
   • Review source code? Rely on the PR's description?
   • This may catch obvious changes, but it seems unlikely to be reliable.
     Especially not with infra changes.