🎉 Database Migrations (that preserve data!)

This release introduces a new system that performs database migrations on existing data (#1343), which was necessary to migrate the Transfers database to correct an out of memory issue at startup for users with a large number of transfer records (see #1291).

Upon first start after upgrading to 0.23.0 the application will apply the initial migration to the Transfers database (transfers.db), if there is one. Depending on the system and the amount of data present, this may take a while, and the UI will be inaccessible during the process.

Backups of existing databases are taken prior to the start of the process (you can find them in /data/backups) and they aren't deleted automatically, so your historical data is safe. A feature to add auto deletion after a period of time will come later.

In the unlikely event that the process fails to complete successfully, follow the directions in the new migration docs, which explain what to do if something goes wrong, and how to get the application back to a working state if the migration can't be completed.

If you find that your database can't be migrated successfully, please file an issue and I can work on providing a standalone migration tool.

What's Changed

• Add a system to perform database migrations by @jpdillingham in #1343
• Fix remaining transfter State queries using HasFlag() by @jpdillingham in #1356
• Extend health check startup to 60 minutes, set $SHELL for docker container, and bump the GC memory limit from 500MiB to 2GiB by @jpdillingham in #1359
• Bump Soulseek.NET to 7.1.0 by @jpdillingham in #1363
• Update documentation for scripts by @jpdillingham in #1384
• Bump http-proxy-middleware from 2.0.6 to 2.0.9 in /src/web by @dependabot in #1329

Full Changelog: 0.22.5...0.23.0