What should be default RollForward for component projects

We haven’t made an official decision on the default value for RollForward in our new component scenarios.

TLDR; Should we use LatestMinor or LatestMajor for component projects by default.

The long version: Currently RollForward is set to Minor (roll to closest available version while staying with the same major. part of the version, then roll to latest patch of that version) for all projects by default. This is the value used when no RollForward is specified by the SDK in .runtimeconfig.json. More details about RollForward are here and here.

For dynamically loaded components this value would come with problems. The most important one being ordering issues. For example let’s have two COM components A 3.0 Minor and B 3.1 Minor on a machine which has both 3.0 and 3.1 installed. If the native app activates B first, it will load 3.1 runtime and then when it activates A second it will just work (since A can run on 3.1). But if the app activates A first, it would load 3.0 (closest available match to 3.0 Minor) and then when it would try to activate B that would fail (B is not compatible with 3.0).

To overcome this problem the RollForward has two settings:

• LatestMinor – pick the highest available version with the same major. part of the version (so 3.0 LatestMinor would roll to latest 3.* version)
• LatestMajor – pick the highest available version (all up)

If in the above scenario A would be 3.0 LatestMinor and B would be 3.1 LatestMinor, no matter which one got activated first, they both would load 3.1 (as the latest 3.* available version).

So to make it easy for users and make things just work out of the box, we would like to set RollForward to one of the LatestMinor/LatestMajor by default on component projects. Elinor has a PR out which introduces the notion of “component project”: https://github.com/dotnet/sdk/pull/3305

The question is if we should use LatestMinor or LatestMajor as the default for component projects.

LatestMinor:

• Pros: Higher chance of providing the expected compatibility – in general we try really hard to avoid breaking changes for minor versions, so 3.1 is expected to be fully backward compatible with 3.0. We tell people that upgrading to minor version is “safe”.
• Cons: Come .NET 5 components targeting 3.0 would not run on 5.0. Basically creating an upgrade problem. Combining components targeting both 3.0 and 5.0 would fail.

LatestMajor:

• Pros: No upgrade problems – all components run everywhere and together.
• Cons: Potentially breaking for some components as we may introduce some breaking changes between 5.0 and 3.0. That said classlibs (which components are a special case of) are already assumed to work just fine even across major versions (NuGet has no notion of compatibility ranges, and will let people use 3.0 classlibs in 5.0 projects).

Some related discussions already happened: https://github.com/dotnet/core-setup/issues/5870 https://github.com/dotnet/core-setup/issues/5062

Thoughs?

[vitek-karas]

LatestMinor it is - code change made in #3305

[vitek-karas]

@jkotas In that case even LatestMinor is risky as installing new minor release could still break things. That said I agree we’re much more careful about changes in minor releases.