declare and bump DependencyModel to 8.x #13473
Conversation
| @@ -42,7 +42,7 @@ | |||
| <!-- runtime --> | |||
| <MicrosoftExtensionsDependencyInjectionAbstractionsVersion>6.0.0</MicrosoftExtensionsDependencyInjectionAbstractionsVersion> | |||
| <MicrosoftExtensionsDependencyInjectionVersion>6.0.0</MicrosoftExtensionsDependencyInjectionVersion> | |||
| <MicrosoftExtensionsDependencyModelVersion>6.0.0</MicrosoftExtensionsDependencyModelVersion> | |||
| <MicrosoftExtensionsDependencyModelVersion>8.0.0-preview.5.23259.1</MicrosoftExtensionsDependencyModelVersion> | |||
There was a problem hiding this comment.
How did you choose this version? Why is the previous 6.0.0 version not simply overridden by the previously source built version?
There was a problem hiding this comment.
Previous source-build artifacts don't apply to repo source-build legs. e.g. this was not a problem in the product source-build rather it is a problem when consuming the arcade intermediate.
There was a problem hiding this comment.
Ahh. It's a bit annoying that we have to ensure we choose a version that is not in SBRP. I wonder if there is a better way to do this...would be fantastic to have a way of annotating which inputs should come from SBRP or otherwise.
oleksandr-didyk
dismissed stale reviews from MichaelSimons and mthalman
via
9e96eae
|
IMHO this change looks wrong. Arcade shouldn't depend on an 8.0 Preview package. 7.0.0 should be sufficient. Can you please explain why this change was necessary? |
The linked issue has an adequate outline for why this was done originally - #13471 |
|
I did read the linked issue but I still don't understand why we change the version in a non source build environment.
Why don't we use the N-1 toolset version as we do with other dependencies? Why do we force the non source build to use a preview version of a package? That goes against what we usually do in Arcade (depend on the latest stable version). |
We are. Version N-1 is the version of the latest available source build of a given component. In the context of repo build, this would mean the latest version available at the time of the build, which can be a preview version. N-1 here does not refer to the previous release though.
Ideally we want the source-build and the non source-build to be identical. This allows us to surface issues as soon as possible so their impact is minimal + we are confident that there is no difference in behaviour between the two. Pre-built detection and repo PvP initiatives are both to some extent aimed at achieving this goal. |
|
@oleksandr-didyk I think we should be choosing a version that aligns with the latest preview release, not the latest version. I don't think it's great to have a subscription from runtime->arcade. In this case it would be the preview 4 release of |
Sure thing, can do - #13718 Is there some existing process that can guarantee that the repo maintainers would update this version after a new preview is available? |
Resolves #13471
Tested by building an intermediate of Arcade locally and giving it to
runtime. Both builds succeeded without any issues.Will create a subscription for the live version after the PR is approved.