v0.0.30

Before you upgrade

Until the first public release, nothing upgrades a database in place. A build whose database schema differs from the one your instance holds refuses to start on it, changes nothing in the file, and says so in its log. The build that wrote the file can still read it, so going back to that build brings the instance back.

To try carrying your data into this build, take an export with the build that wrote the file (GET /export?format=archive&state=any), start this build on a fresh file, and restore the archive there (POST /restore). The state=any parameter includes trashed items. Until the first public release, archive compatibility is guaranteed only for the build that wrote the archive. Another build can refuse it, and a successful restore does not guarantee that every field from the original database was preserved. Keep the original database, its build, and the export so you can return to the original instance.

In the container image, a refused database leaves the container running and unhealthy, with the message in its log, rather than restarting it into the same refusal. deploy/README.md says what to do next.

What's Changed

• fix(server): bound backup test disk usage by @aicayzer in #2367
• fix(core): write back no file moved to another folder from a remote change by @aicayzer in #2345
• feat(server): add system.view and the /views door by @aicayzer in #2359
• feat(core): fetch files larger than the file budget by @aicayzer in #2368
• feat(core): hydrate a slice of every type by * alone by @aicayzer in #2369
• feat(folders): rename search to query and accept all tiers by @aicayzer in #2371
• test(conformance): isolate cleanup and image sweep assertions by @aicayzer in #2373

Full Changelog: v0.0.29...v0.0.30