Roll forward policy changes

[steveharter]

Roll-forward policy changes have been requested for 2.1.

A framework version is identified by [major.minor.patch]. This issue only pertains to [major.minor] roll-forward because [patch] roll-forward is a separate setting, and no changes are planned for 2.1 for that.

For compatibility, we always want to run on the [major.minor] of the framework that an app targeted, even if newer [major.minor] versions are available on the local system. However, if the [major.minor] is not available on the local system, the following changes are planned for 2.1:

1. Automatically roll-forward on [minor]
   -- In 2.0, this is possible but not enabled by default
2. Automatically roll-forward from release->preview on [minor] and [patch] (if patch roll-forward is enabled)
   -- In 2.0, this is not possible
   -- Try to roll-forward to only release versions. Roll-forward to closest preview version only when there isn't a compatible release version

Also (unless there is feedback otherwise) we plan to keep the existing semantics of not allowing preview->release roll-forward. When a preview build is specified we only roll forward if the specified preview version doesn't exist, and only roll forward to preview versions that have the same [major.minor.patch] and never to release versions.

We need to determine what settings are available to control these. There is existing support for roll-forward-on-no-candidate-fx which has environment variable, runtimeconfig.json and argument support to control the major and minor roll-forward (patch roll-forward is controlled by a different setting). One quirk with this setting is that it enables [major] roll forward, which is not desired (by default anyway).

One option is to extend the roll-forward-on-no-candidate-fx setting into three values:

0. Off.
1. Roll forward on minor
2. Roll forward on major and minor

The default value would be (1). For the --roll-forward-on-no-candidate-fx argument, an additional value can be provided (0, 1 or 2) otherwise the default value of (1) will be applied.

[steveharter]

Update: I am currently prototyping this for preview1

[Petermarcu]

I believe this all matches my understanding. thanks for writing it up.

[piers7]

"we plan to keep the existing semantics of not allowing preview->release roll-forward"

Could you guys elaborate on why? That seems a strange choice to me - I'd have thought semver-like semantics of rolling forwards from a preview to the matching release would have been a fairly safe approach. Given a choice between 'running, if it can' and 'refusing to run', the latter seems somewhat ... harsh?

[steveharter]

@piers7 there has not been any requests for preview->release yet AFAIK. If you have scenarios, please share them.

If an app targets a preview release, the app would re-target to the version to the release version when it is available and tested. Until that time, the app is preview as well. That makes sense.

However one issue is that there is a bit of a timing issue here - an app won't work on the release version without being re-targeted, which can be considered kind of harsh as you stated. Plus there are no knobs to control the preview->release roll-forward; is it always disabled. So this is one scenario that I'm aware of, but is by-design to err on the side of safety\compat and correctness.

Some options:

1. Leave the policy as-is. No preview->release roll-forward (current plan of record)
2. Add knobs to allow roll-forward behavior (roll-forward-on-no-candidate-fx or other)
3. Roll-forward treating a preview version ([major][minor][patch][name][build]) the same as a non-preview meaning ignore the [name][build]
4. ?

[nguerrera]

There seem to be some contradictions in the description:

This issue only pertains to [major.minor]

vs.

Automatically roll-forward from release->preview on [minor] and [patch] (if patch roll-forward is enabled)

vs.

Also (unless there is feedback otherwise) we plan to keep the existing semantics of not allowing preview->release roll-forward

[nguerrera]

Oh I see the 2nd point above is about release->preview and the last point is preview->release.

I find it very surprising and confusing that preview->release would not be supported wherever release->preview would.

[steveharter]

On this contradiction:

Automatically roll-forward from release->preview on [minor] and [patch] (if patch roll-forward is enabled)

The [patch] roll-forward handled separately from (and after) [major] \ [minor] roll-forward, so I was just pointing out that [patch] roll-forward would continue to work as expected, and we aren't changing semantics here.

[steveharter]

I find it very surprising and confusing that preview->release would not be supported wherever release->preview would.

I'm open here but this is the way it was originally designed - "developer" (preview) roll-forward is completely different than "production" (release) roll-forward.

[steveharter]

I just found there is a preReleaseRollForward bool setting, similar to the bool applyPatches setting, that can be set in the runtimeconfig.json, but it is not used anywhere.

Depending on what we want to do with preview->release we could use this to enable (or disable) the functionality.