Conversation
|
Learn Build status updates of commit 7883fbf:
|
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/release-notes/NuGet-6.11.md | View | Details |
docs/release-notes/NuGet-6.11.md
- Line 4, Column 9: [Warning: author-not-found - See documentation]
Invalid value for author: 'mruizmares' is not a valid GitHub ID.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
|
@zivkan @donnie-msft @nkolev92 I updated the issues with the correct milestone, let me know if there are some that are missing. |
|
Learn Build status updates of commit 02c0e2b: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
docs/release-notes/NuGet-6.11.md
Outdated
|
|
||
| * `MSBuildRestoreUtility.GetRestoreAuditProperties` needs a breaking change to read `NuGetAuditSuppress` items - [#13313](https://github.com/NuGet/Home/issues/13313) | ||
|
|
||
| * NuGetAudit should check transitive packages by default when the .NET 9 SDK is installed - [#13293](https://github.com/NuGet/Home/issues/13293) |
There was a problem hiding this comment.
This one is tricky. It technically matches 9.0 and VS 17.12, but it's something that could be helpful for people to know.n
There was a problem hiding this comment.
yeah, I wasn't sure about commenting on this one either.
I don't think there are any scenarios where this really matters to customers. Even if the customer is using nuget.exe, I don't think it matters if they're using nuget.exe 6.11 or 6.10, in both cases I'd expect the project to load the SDK's nuget.targets, not nuget.exe's targets, and therefore it's still the version of the SDK that matters, not the version of NuGet.
But the change to nuget.targets, that adds the version check for the .NET 9 SDK, is added to nuget 6.11. 🤷
There was a problem hiding this comment.
Even if the customer is using nuget.exe, I don't think it matters if they're using nuget.exe 6.11 or 6.10, in both cases I'd expect the project to load the SDK's nuget.targets, not nuget.exe's targets, and therefore it's still the version of the SDK that matters, not the version of NuGet
I actually think it's opposite. In fact, I'm pretty sure it is: https://github.com/NuGet/NuGet.Client/blob/9fbabf9a119599b62824f676407c5611c0542781/src/NuGet.Clients/NuGet.CommandLine/MsBuildUtility.cs#L263.
You still need .NET 9 of the SDK.
It almost feels like this particular issue could be referenced in both 6.11 and 6.12 since 6.12 matches .NET 9.
I feel like it's needed in 6.12, but 6.11 is more optional.
There was a problem hiding this comment.
Since it's in the breaking change section I think leave it is better
There was a problem hiding this comment.
Should we call this a feature instead of a breaking change?
@zivkan Our breaking change section was meant to be for APIs. This is more of an addition/roll out.
There was a problem hiding this comment.
Sorry, I forgot to reply to this earlier. In case it's still useful, we can continue the conversation
Our breaking change section was meant to be for APIs
Where was this communicated? If this is not obvious to customers reading the release notes, then I disagree that we should keep it for API breaking changes only. If a customer is experiencing problems with a new release, it's faster for them to check the release notes and look at a short list of breaking changes, compared to (what's hopefully) a longer list of features.
There was a problem hiding this comment.
I feel like the new feature section gets more prominence the breaking changes section by virtue of headings.
I added the original breaking changes section and that was pretty much my interpretation.
Another thing is that transitive vulnerabilities aren't a traditional breaking chnage, they're a new feature. I'd rather have the precedent where we can make calls like this.
Honestly, having a flagship feature in the breaking changes section doesn't do it the service it deserves.
|
Learn Build status updates of commit 324b53c: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
|
Learn Build status updates of commit a71a417: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
|
Learn Build status updates of commit ffcd1d9: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
4 participants
Release notes for https://github.com/NuGet/Client.Engineering/issues/2907