PM UI VersionRange constraint updates - #15002
Conversation
Define how Package Manager UI preserves authored version ranges for in-range updates and replaces them for explicit out-of-range selections. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 87d3cdd3-17dd-489c-ae2e-bb498e755f1d
| Visual Studio Package Manager UI (PM UI) will respect upper-bounded and | ||
| floating PackageReference version ranges when finding and applying updates. |
There was a problem hiding this comment.
we normally format markdown as one line per sentence, not manual line wrapping
| This proposal applies only to PM UI. Package Manager Console, | ||
| `dotnet package update`, and other update entry points are outside its scope. | ||
| It is intentionally a partial solution to | ||
| [NuGet/Home#6566](https://github.com/NuGet/Home/issues/6566). |
There was a problem hiding this comment.
Are you suggesting that some time in the future when dotnet package update supports some kind of similar functionality, it's acceptable for it to do so in a way that behaves differently to PM UI?
Even if the initial implementation is only in PM UI and not dotnet package update, I would expect them both to have the same behavior and therefore this is a spec for all NuGet update scenarios, not just PM UI.
There was a problem hiding this comment.
I was trying to scope this spec only to PM UI, but yeah dotnet package update should behave the same, that is a bigger discussion that I was trying to avoid but it's needed.
| ### Preserve ranges only for in-range updates | ||
|
|
||
| Routine updates should not erase a customer's authored boundary. Setting the | ||
| lower bound records the update while retaining the upper-bound policy. | ||
|
|
||
| ### Replace the range for an explicit out-of-range selection | ||
|
|
||
| Selecting an out-of-range concrete version is an explicit request to leave the | ||
| current constraint. Replacing it with the normal minimum-only PackageReference | ||
| version is predictable and does not require PM UI to infer a new policy. |
There was a problem hiding this comment.
Was this entire spec written by AI? I haven't yet started reading the other subheadings under "rationale and alternatives", but these two are repeating what the rest of the spec already explained. I suspect the AI saw that this is a rationale section and is now trying to justify it, but I feel like it's making it harder for me to read.
| ### Do not shift or widen the range automatically | ||
|
|
||
| PM UI could infer `[9.1.0, 10.0.0)` or widen the old range, but either behavior | ||
| guesses the customer's intended upper bound. The customer can author a new | ||
| range separately when needed. |
There was a problem hiding this comment.
this only makes sense if you remember that most of the previous examples used the example of updating to version 9.1.0 when the previous range was [8.0.0, 9.0.0). Otherwise, this paragraph is quite confusing.
| ### Use the existing PackageReference range | ||
|
|
||
| Using the existing `Version` or `PackageVersion` range avoids a new project | ||
| model contract. A future update-only constraint could separate update policy | ||
| from restore semantics, but that is outside this proposal. |
There was a problem hiding this comment.
When a project is packed, the PackageReference version range becomes the package dependency's version range. Overloading the Version therefore prevents having separate controls.
For example, I don't believe that Microsoft.Extensions.DependencyInjection has ever had a breaking change. If I want to stay on the 10.* package versions until I retarget my project to net12..0, that doesn't mean my package is incompatible with 11.* packages. Only, I don't want NuGet to suggest those versions as an upgrade.
The prior art section already mentions packages.config's allowedVersions attribute, but this alternatives section says it doesn't want to introduce a "new project model contract", while failing to acknowledge that an upper range in the existing Version already has a semantic meaning.
Additionally, "A future update-only contraint could superate update policy from restore semantics" is basically saying we can introduce breaking changes in the future. I think it's better to introduce something different now, so that we don't need breaking changes in the future.
Going back to customer intent, I think customers are trying to use Version="[8.0.0, 9.0.0)" not because they believe that version 9 and above are incompatible with their project, but as an attempt to get this "update range" behavior, before they find out that it doesn't actually work that way. So, I feel like this proposal is reinforcing customers believe of using the wrong tool for the job. I think we should implement a separate allowedUpates="[8.0.0, 9.0.0)" or allowedUpdate="8.*" instead, and leave the version to retain its existing compatible version semantics.
The behavior in this spec still makes sense when a package is incompatible with higher versions, so the developer wants to bump the version and keep the max compatible version. But the motivation in this spec is not aligned with that scenario.
|
Pr review meeting: @martinrrm should we have a spec review discussion on this? |
dotnet-policy-service
Bot
added
the
Status:No recent activity
|
This PR has been automatically marked as stale because it has no activity for 30 days. It will be closed if no further activity occurs within another 15 days of this comment, unless it has a "Status:Do not auto close" label. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
3 participants
rendered version: https://github.com/NuGet/Home/blob/d16985ab8369de7d3ac82c41843d6093d7097c60/accepted/2026/package-update-version-constraints.md
Description
Adds a PM UI-only design for respecting authored
PackageReferenceversion constraints during updates.The proposal defines how PM UI: