What should be default RollForward for component projects
See original GitHub issueWe 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 samemajor.
part of the version (so3.0 LatestMinor
would roll to latest3.*
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
and3.0
. That saidclasslibs
(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 use3.0
classlibs
in5.0
projects).
Some related discussions already happened: https://github.com/dotnet/core-setup/issues/5870 https://github.com/dotnet/core-setup/issues/5062
Thoughs?
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (9 by maintainers)
LatestMinor
it is - code change made in #3305@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.