.NET 8 Build Plan

[richlander]

.NET 8 Build Plan

We aspire to significantly change the way the .NET build works. Over time, we intend to deliver a single build system for all users. We cannot pull that off in one release, both in terms of cost but also in terms of risk to the release (the build is foundational). This issue describes the investment we plan to make for .NET 8 across multiple dimensions. The decisions are not exactly a reflection of priority, but an attempt to draw a pragmatic straight line from where we are now to where we want to be.

During this timeframe, we intend to deliver a significantly improved community-based build but for Microsoft to maintain its own proprietary system. We intend for Microsoft to abandon its proprietary build in .NET 9 and to adopt the community-based build from that point on.

Plan:

• Virtual mono repo (VMR) lite
  • Source-build switches from producing a tarball to being in a persistent git repo.
  • Each product commit would be a release (like 8.0.0 -> 8.0.1). The behavior for previews (what's in a commit) would be different (perhaps one commit per nightly successful build).
  • Automation would flow changes into the VMR from the atomic repos (like dotnet/runtime and dotnet/aspnetcore)
  • Automation would not be available (in this release) to flow changes back into the atomic repos (that's the "lite" part)
• Source build capabilities
  • Linux only + distro-specific (no change; just like SB is now)
  • Prepare build for macOS and Windows builds to be added later. In particular, supporting multiple distinct platforms and as little sharing of built assets as possible. This includes removing Windows-specific assets from the Linux build (which exist today).
  • Add tests for validating .NET built via SB.
  • [Stretch goal] Add "portable Linux" build flavor (not to replace distro-specific flavor).

In terms of value (to .NET team, distro maintainers, and the general public), this plan offers the following value:

• A persistent repo that isn't dependent (for its existence) on the Microsoft proprietary build (and can be used after Microsoft stops supporting a given .NET version).
• Enables a whole-product space for making cross-product changes, like breaks and experimentation (valuable even without backflow to the atomic repos).
• Reduce the size of Linux builds by removing Windows-only assets.
• [Strech goal] Unlocks portable Linux as an MS-only capability.

In terms of a longer-term roadmap, this plan offers:

• The Microsoft official build is kept as-is de-risking shipping .NET 8.
• We de-risk the .NET 9 release by figuring out our multi-platform vertical build strategy now.
• we can add macOS and Windows support as straightforward add-ons once the vertical strategy is sorted out.

[omajid]

@dotnet/distro-maintainers are there any major concerns you see with this plan?

[asbjornu]

@omajid, I think the plan is great, but wonder what consequence it will have for macOS that support for it won't be added until after .NET 9?

[richlander]

There isn't intended to be any take-back. It's whatever the macOS support is for source-build today. Perhaps you can help us with that (with filing macOS specific bugs) as we move forward.

[ayakael]

From the perspective of Alpine Linux on the move to VMR, It'd be nice to maintain the possibility of building from within a stripped down tarball. Our build system is based on the existence of a tarball one can pull and checksum to confirm reproducibility. For .NET 6 / 7, we build the tarball and host in our server. I've also created a patch for .NET 6 to build reproducible tarballs so that every time it is built it produces the same checksum (#2780).

With that said, I'm excited by the prospect of normalizing builds between Microsoft and community. That'll be a benefit to both ecosystems.