@frobijn I've fixed the checklist for you.
FYI, the correct format is [x], no spaces inside brackets, no other chars.

Walkthrough

The changes update the GitHub Actions workflows for generating changelogs for both the VS2019 and VS2022 versions. Specifically, the "Update changelog in release" step in each workflow is modified to use version v1.3.1 of the tubone24/update_release action instead of the previously used v1.0. No other modifications to the workflow logic, environment variables, or control flow are present.

Changes

Assessment against linked issues

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

This task is doing more than the "announced": its cleaning up stuff in the nfproj file depending on what is listed in the packages lock file.
It runs on every build, so it adds time to the build and, 99.999999% of the time, won't be doing anything useful.

I would rather see this fixed upstream and have the task do whatever it needs to do when a package is added/updated rather than running on every build.
I've added a mention to this on the NuGet issue referenced above.

Being a "one-time" event (like when creating a new lib and adding the imports to StyleCop) I'm more than fine to accept the fact that I have to manually edit the nfproj once and that's it.
As far as I understand it (at least it works with nbgv) as long as the imports are in the nfproj file, the update process takes care of updating the versions. At least that's what happens with nbgv...

This task is doing more than the "announced": its cleaning up stuff in the nfproj file depending on what is listed in the packages lock file.

It is a synchronization of the packages.config indeed. AFAIK, based on the NuGet code, only packages listed in packages.config are investigated for *.props and *.targets files. And all imports that result from this mechanism are uniquely identified by their path: "<package id>....". The "algorithm" is exactly the same as the NuGet code uses, so it functionally is an exact copy of the behavior that is lacking.

It runs on every build, so it adds time to the build and, 99.999999% of the time, won't be doing anything useful.

I don't think there is any other way than to run a task every build. But if you have ever looked at the detailed log of a build, an extra task add only 0.000000001% to the total execution time of a build. There is a lot of stuff going on that is completely unnecessary, but that's the way a build works.

If you are unhappy about the 0.000000001% time increase, there are ways to optimize performance. E.g., by writing the hash and/or date/time of packages.config in a file "obj\nF\package.sync" and only running the full task if the packages.config is out of date.

I would rather see this fixed upstream and have the task do whatever it needs to do when a package is added/updated rather than running on every build. I've added a mention to this on the NuGet issue referenced above.

I've also tried to poke Microsoft via the issue that I've created about this. All that is met with a deafening silence. I don't think a reaction will be given before nanoFramework switches to the new project format.

There may be another way to hook into that via extensibility interfaces: https://learn.microsoft.com/en-us/nuget/visual-studio-extensibility/nuget-api-in-visual-studio#ivspackageinstallerevents-interface, but I have no clue how to program those and I can't find any code examples.

Being a "one-time" event (like when creating a new lib and adding the imports to StyleCop) I'm more than fine to accept the fact that I have to manually edit the nfproj once and that's it.

Unless you are a user like AlbertK and have no clue why your package is not working. I don't think this task is primarily meant for you. I have several packages that use the msbuild-mechanism (and yes, I'll still plan to make PR's for them) that are used by multiple projects, and a manual update of the projects for new package versions is quite a tedious job (I don't have Azure pipelines for that).

As far as I understand it (at least it works with nbgv) as long as the imports are in the nfproj file, the update process takes care of updating the versions. At least that's what happens with nbgv...

No it doesn't. If you have a valid .nfproj file with the imports and use the package manager to change the installed version of nbgv, none of the imports are updated. For nanoFramework repositories you may not encounter this as the version updates seem to be updated by one of the pipelines.

So, what do you want to do with this PR? It's fine with me if you still don't like it. Then I'll integrate this task in my collection of build tools and stop nagging about this issue.