search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.19k stars 1.35k forks source link

Request to backport getResultOutputFile from 8.0.3xx to 8.0.1xx SDK. #10181

Open tmds opened 2 months ago

tmds commented 2 months ago

https://github.com/dotnet/msbuild/pull/9640 introduced the getResultOutputFile which makes it possible to redirect the project evaluation output into a separate file. This feature has now become available as part of the 8.0.3xx SDK

We'd like to use this feature on a source-build .NET 8 SDK.

The source-built .NET 8 SDK is limited to the 8.0.1xx series, so the feature needs to be backported.

The backport can happen upstream (shared in this repo) or we can do it as package maintainers (each maintainer separately).

I'm opening the issue to request the backport, and to increase awareness about the feature gap between Microsoft and source-built SDKs.

cc @omajid @baronfel @Forgind @rainersigwald

rainersigwald commented 2 months ago

I'd like to understand more about the landscape here. Are there other tooling ecosystems with distros-take-only-intermittent-releases? If so, are they generally backport-friendly or forked?

From the MSBuild team perspective, we have three ship vehicles:

  1. Source-build distro SDKs (at 8.0.1xx for a year)
  2. Microsoft-built .NET SDK (update MSBuild quarterly, support cadence for patches follows VS)
  3. Visual Studio (updates quarterly, has LTS releases with longer support lifecycles for fixes but not new features)

MSBuild 17.8, which shipped in .NET 8.0.100 and VS 17.8, is in kind of an awkward spot: the VS flavor is supported for fixes until July 2025, but VS would not want to take a new feature like this as a backport. Conversely the source-build SDK would want new features backported.

tmds commented 1 month ago

Are there other tooling ecosystems with distros-take-only-intermittent-releases? If so, are they generally backport-friendly or forked?

@omajid may be you have some insights?

MSBuild 17.8, which shipped in .NET 8.0.100 and VS 17.8, is in kind of an awkward spot: the VS flavor is supported for fixes until July 2025, but VS would not want to take a new feature like this as a backport. Conversely the source-build SDK would want new features backported.

We need to try address the general issue of the feature gap.

Specifically for getResultOutputFile. Do you think we can have a backport of getResultOutputFile to 8.0.1xx on the short term (available by august/september)? Or is that not likely?

omajid commented 1 month ago

Are there other tooling ecosystems with distros-take-only-intermittent-releases? If so, are they generally backport-friendly or forked?

I don't think there's a common answer. It varies per project. Often it's a mix of both.

Projects like OpenJDK, python and gcc have a large set of contributors representing different organizations (or no organization). The releases are also self-driven and aren't tied to other products (like IDEs/Visual Sudio). So, when evaluating changes, these projects are primarily deciding "is this something we think will benefit our project or not?" The exact policies for backporting generally vary between projects and even release branches, and also depend on the length of support of a release branch.

Forking, to some extent, is guaranteed. Almost every distro taking a tool needs to make some changes to it. For example:

These projects have some differences from .NET, though. In particular, contributions/maintenance is primarily driven by Microsoft for .NET, and the ability for non-Microsoft contributors to create, test, verify and ship additional changes is much more limited. IMO, we non-Microsoft contributors also have an additional risk for de-stabilizing or breaking .NET when we make changes that are not merged/tested as part of the .NET project.