Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major-version roll-forward options for Core 3.0 #12237

Closed
Thraka opened this issue May 7, 2019 · 10 comments · Fixed by #25039
Closed

Major-version roll-forward options for Core 3.0 #12237

Thraka opened this issue May 7, 2019 · 10 comments · Fixed by #25039
Assignees

Comments

@Thraka
Copy link
Contributor

Thraka commented May 7, 2019

Major-verison roll-forward has been added as an opt-in feature in Core 3.0. This should be documented in the version roll-foward article: dotnet/core/versions/selection.md

Here is info from the design spec at https://github.com/dotnet/designs/blob/main/accepted/2019/runtime-binding.md

RollForward

RollForward specifies the roll-forward policy for an application, either as a fallback to accommodate missing a specific runtime version or as a directive to use a later version.

RollForward can have the following values:

  • LatestPatch -- Roll forward to the highest patch version. This disables minor version roll forward.
  • Minor -- Roll forward to the lowest higher minor version, if requested minor version is missing. If the requested minor version is present, then the LatestPatch policy is used.
  • Major -- Roll forward to lowest higher major version, and lowest minor version, if requested major version is missing. If the requested major version is present, then the Minor policy is used.
  • LatestMinor -- Roll forward to highest minor version, even if requested minor version is present.
  • LatestMajor -- Roll forward to highest major and highest minor version, even if requested major is present.
  • Disable -- Do not roll forward. Only bind to specified version. This policy is not recommended for general use since it disable the ability to roll-forward to the latest patches. It is only recommended for testing.

Minor is the default setting. See Configuration Precedence for more information.

In all cases except Disable the highest available patch version is selected.

Note: LatestMinor and LatestMajor are intended for component hosting scenarios, for both managed and native hosts (for example, managed COM components).

RollForward can be set in the following ways:

  • Project file property: RollForward
  • Runtime configuration file property: rollForward
  • Environment variable: DOTNET_ROLL_FORWARD
  • Command line argument: --roll-forward

edit by @mairaw: added topic details


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label May 7, 2019
@Thraka Thraka added this to the Backlog milestone May 7, 2019
@sdmaclea
Copy link
Contributor

@mairaw mairaw added the P1 label Oct 17, 2019
@mairaw
Copy link
Contributor

mairaw commented Oct 17, 2019

This also impacts this article https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection, no? /cc @nguerrera

Might need to file a separate issue to break down the work if so.

Mizux pushed a commit to google/or-tools that referenced this issue Jan 8, 2020
i.e. If a user has only >netCore SDK 3.0 installed allow .netcoreapp2.0 to "fallback" to .netcoreapp3.0

ref: dotnet/docs#12237
@mairaw
Copy link
Contributor

mairaw commented Mar 2, 2020

It would be good to prioritize this update. I'm updating the .NET Core support policy page (https://github.com/dotnet/website/pull/1782/) and I'm going to link to this article since the behavior changed over time.

@sdmaclea
Copy link
Contributor

sdmaclea commented Mar 2, 2020

/cc @vitek-karas @richlander

@vitek-karas
Copy link
Member

https://docs.microsoft.com/en-us/dotnet/core/versions/selection is still correct - none of the info there is wrong. The question is how much detail should it have. Note that even on 2.* there was a way to influence the roll forward behavior (RollForwardOnNoCadidateFx and similar settings) and it did support roll forward over Major versions as well. The new RollForward as described in https://github.com/dotnet/designs/blob/master/accepted/2019/runtime-binding.md adds some new functionality and improves the overall behavior to fit more scenarios. But the behavior described in the existing docs doesn't change.

We could leave it as is - basically not adding any description of how to change the default behavior. Just like it was in 2.* with no description of RollForwardOnNoCandidateFx.

Or we could write a new page which would be basically a docs rewrite of the spec in https://github.com/dotnet/designs/blob/master/accepted/2019/runtime-binding.md. And then link to that with "here are all the details including how to change the default behavior".

I don't see how https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection is affected. It does use the same terminology (roll forward), but it is describing a different part of the system (SDK) which AFAIK didn't change behavior in 3.0.

@vitek-karas
Copy link
Member

I think there's also a confusion. There are several parts to "roll forward":

@richlander
Copy link
Member

I agree with Vitek, that the document on self-contained shouldn't be using roll-forward in the title.

@mairaw
Copy link
Contributor

mairaw commented Sep 9, 2020

What would be the appropriate terminology for that @richlander?

Should I point to https://github.com/dotnet/designs/blob/master/accepted/2019/runtime-binding.md from the support policy page while these changes are not done?

@dotnet-bot
Copy link
Contributor

This issue has been closed as part of the issue backlog grooming process outlined in #22351.

That automated process may have closed some issues that should be addressed. If you think this is one of them, reopen it with a comment explaining why. Tag the @dotnet/docs team for visibility.

@agocke agocke reopened this Mar 10, 2021
@dotnet-bot dotnet-bot removed the won't fix Issues that were closed as part of automated backlog grooming label Mar 10, 2021
@agocke
Copy link
Member

agocke commented Mar 10, 2021

This still seems like a significant issue -- I can't find the list of RollForward options anywhere else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.