Picard 2.1.2 is available. There are only 3 actual changes to Picard itself (the rest are fixes to our build and release procedure), but those include a possible crash and a bug that can prevent Picard from loading certain releases (showing a false login prompt instead).
More details in the blog:
Nice. Seems to install on Win10 fine. Will give more run out later.
On the v2 installs already on PCs I had I used the new Check for Updates option. Worked well, but that may lead to the odd ID-10T issue where someone runs the installer but doesn’t stop the current Picard that is still running. When I did that I got a error from an in use dll. Would be good if the installer can warn and\or exit the currently running Picard.
Interestingly when I did the update on Win7 it spotted the old 32-bit version was running and gave the correct warning - guess that test needs an update?
The installer still has the bug where it tries to put the new 64-bit version on top of the old 32-bit version. The bug that then crashes due to plugin issues. (Sorry, I don’t have a login to the ticket system, but this has been reported before. Suggested solution to trigger the uninstaller of the 32-bit version before installing the 64-bit version)
Yes, we are aware of that, there is a ticket for this, but nobody has worked on this yet. As most open source projects Picard is heavily limited by available developer time, and a minor issue like non-standard install location in case of update just isn’t too high on the priority list. Especially since this only affects a part of users and there are easy to apply workarounds available for those who care.
I added an issue at https://tickets.metabrainz.org/browse/PICARD-1460
We have code that is supposed to do this, but it apparently this does not work as it should on Win 10.
Not sure if it is win10 or the swap to 64-bit that changed the test. It was funny how I wrote the bug report and then saw it work perfectly on the upgrade from v1.42 to v2.x on Win7.
I already identified the cause for that and will submit a fix. It was actually the upgrade to Qt5 in Picard 2 that changed how windows are named and causes the detection to fail. Thanks for spotting and reporting this issue.
Nice one. 
I’ve usually got some victim machine around to throw those tests at… time allowing.