v0.0.35

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.

Changes that need action

• Views hold no layouts. A view is a title, a query, an optional sort and an optional group. A request that sends layouts or a layout option is refused 400 validation_error. A view saved with layouts drops them the next time it is changed. marfa device items list --layout and marfa device views groups --layout are gone, and so is a group's sum. Send group: null to clear a grouping (#2391).
• Notes, articles and messages no longer require a body (#2392).

New

• A view filters by an edge and by source through its filter. A working copy answers a backref condition where it holds that edge type whole (#2391).
• Every edge type names both ends. label names the source end, and the optional reverse_label names the target end. Without reverse_label, the label names both ends, which is a two-way relation. Without label, one is made from the id (#2394).
• Moving a type is one step. POST /types/{id}/move and marfa types move move every item of a type, items in the bin included. Once nothing of the old type is left, they rewrite the folders, views and webhooks that name it. DELETE /types/{id} refuses while a folder, view or webhook names the type, and lists them (#2395).
• Every attached file comes down into a folder beside its document, embedded or not (#2393).

Fixed

• A folder pull no longer deletes and rewrites an attached or embedded file on every pass when a second folder on the same machine also holds it (#2393).

What's Changed

• test(server): give the audit census room on a busy runner by @aicayzer in #2384
• chore(deps): bump undici from 8.11.2 to 8.12.2 by @dependabot[bot] in #2360
• feat(types): stop requiring body on notes, articles and messages by @aicayzer in #2392
• test(cli): read the whole request before answering on the test socket by @aicayzer in #2396
• feat(views): hold a view's sort and group, not layouts by @aicayzer in #2391
• feat(edges): name both ends of every edge type with a label and a reverse label by @aicayzer in #2394
• feat(server): move a type's items in one step by @aicayzer in #2395
• feat(core): write every attached file beside its document by @aicayzer in #2393

Full Changelog: v0.0.34...v0.0.35

v0.0.34

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

• chore(deps): bump zod from 4.6.5 to 4.6.6 by @dependabot[bot] in #2356
• test(core): keep a stalled watch from breaking the told-once count by @aicayzer in #2382
• test(ci): send no telemetry from test runs by @aicayzer in #2381
• fix(core): stop idle folder watches running a pass every second by @aicayzer in #2380

Full Changelog: v0.0.33...v0.0.34

v0.0.33

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): drop undeclared settings on folder changes by @aicayzer in #2379

Full Changelog: v0.0.32...v0.0.33

v0.0.32

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

• feat(core): refill an aged-out copy in place and queue writes by @aicayzer in #2375

Full Changelog: v0.0.31...v0.0.32

v0.0.31

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

• feat(core): resume an interrupted hydration from the page it reached by @aicayzer in #2370
• feat(core): read and aggregate saved views offline by @aicayzer in #2374
• feat(core): keep attachments of held items offline by @aicayzer in #2372
• feat(core): create change and delete views through bindings by @aicayzer in #2377

Full Changelog: v0.0.30...v0.0.31

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

v0.0.29

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

• docs(glossary): retire promote and transitory for moves between tiers by @aicayzer in #2341
• feat(server): keep the event log for 30 days by default by @aicayzer in #2343
• refactor(contract): rename the read view to reach by @aicayzer in #2344
• docs(agents): say when a release is cut and who cuts it by @aicayzer in #2350
• test(cli): keep the suite independent of MARFA_NO_KEYCHAIN in the shell by @aicayzer in #2348
• feat(conformance): benchmark a device filling a large image library by @aicayzer in #2352
• test(core): scope the replace-refused fault to the thread that sets it by @aicayzer in #2354
• feat(types): core.file.image and core.media declare a thumbnail by @aicayzer in #2355
• feat(cli): add named profiles with a key command by @aicayzer in #2346
• feat(core): bound the file cache with a budget sized to the disk by @aicayzer in #2347
• perf(server): read a type-filtered listing page in index order by @aicayzer in #2357
• feat(core): answer reads from a copy a hydration is filling by @aicayzer in #2363
• feat(core): expose the public instance description by @aicayzer in #2365

Full Changelog: v0.0.28...v0.0.29

v0.0.28

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(core): write back no file moved or deleted during a folder pass by @aicayzer in #2322

Full Changelog: v0.0.27...v0.0.28

v0.0.27

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

• feat(cli): help a docs miss, read one docs section, print safely by @aicayzer in #2317
• feat(cli): let the login agent take its key from a key file by @aicayzer in #2318
• feat(cli): draw color on a terminal only, with a test that piped output stays clean by @aicayzer in #2319

Full Changelog: v0.0.26...v0.0.27

v0.0.26

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

• test(server): stop the S3 signing clock test reading the peer's Date by @aicayzer in #2302
• feat(core): replace a refused working copy with nothing unsent by @aicayzer in #2301
• fix(server): stop underlining console list rows on hover by @aicayzer in #2304
• refactor(server): move the last old-layout pages onto the page system by @aicayzer in #2307
• feat(server): bring back the ui viewer for the page system by @aicayzer in #2309
• feat(server): follow links between pages in the ui viewer by @aicayzer in #2314
• ci: run only the workspace job for the ui viewer by @aicayzer in #2316
• feat(server): upload the owner's profile picture instead of a web address by @aicayzer in #2306
• feat(cli): say where a tunnel points, which machine, and where the docs are by @aicayzer in #2315

Full Changelog: v0.0.25...v0.0.26