Skip to content

SaiLoR v1.3.0

Latest

Choose a tag to compare

@Gram21 Gram21 released this 27 Jul 17:50
bcff277

SaiLoR v1.3.0

Since v1.2.1.

⚠️ The web/browser build is discontinued

SaiLoR is now desktop (Electron) only. Browser file-system limitations — the File System Access
API's reach and reliability across browsers — made too many features (multi-file saving, git)
impossible to support properly there. Opening the web build now shows a notice pointing you at the
desktop app, instead of any file-opening UI.

If you were using SaiLoR in a browser or via the Docker/static-hosting deployment: switch to the
desktop app (see the releases page). Your existing
project JSON files open in the desktop app unchanged. Static hosting and the production Docker image
are discontinued along with it, since they only ever served the browser build.

Project storage split into project.json + annotations/ — automatic migration

A project used to be one big JSON file, with every reviewer's and every consolidated answer inline.
That made two reviewers working on different papers — or different reviewer slots of the same
paper — collide in git constantly: any two saves touched the same file, so ordinary diffing and
merging fought over unrelated changes.

Projects are now split on disk:

my-review/
├── project.json          # schema, protocol, screening config, paper metadata — no answers
└── annotations/
    └── <paperId>/
        ├── consolidated.json   the single/consolidated result for this paper
        └── reviewer-<n>.json   each reviewer's own tree (multi-reviewer projects)

Files are created only once a reviewer actually writes something for that paper, and removed again
if cleared back to empty. A screening project uses screening-consolidated.json /
screening-<n>.json instead, so the two kinds of per-paper decision are distinguishable at a glance.

What this means for you:

  • Opening an old-format project works completely unchanged — the app still reads the old
    single-file shape. The next time it's saved, it's rewritten into the new split layout
    automatically. No action needed, no explicit "migrate" step.
  • If you share a project via git with other reviewers, everyone should be on v1.3.0+ before
    anyone saves into the new layout — an older SaiLoR version won't know how to read the split
    annotations/ folder back into a project. Once everyone has upgraded, the merge-conflict problem
    this exists to fix goes away on its own.
  • Papers in the saved file are now ordered by a plain string comparison on their id (not their
    title) — deterministic regardless of locale, and no longer reshuffled if someone edits a title.

Git: switch branches, including creating new ones

The Git panel's header is now a branch switcher. Picking a different branch with nothing uncommitted
just checks it out. With uncommitted changes, it asks: commit first (cancels the switch for now),
carry the changes into the new branch (merging field by field — the same engine Pull already used),
or cancel. "+ New branch…" creates a branch at the current commit and switches to it right away;
since a fresh branch shares its parent's commit, carrying changes into it can never itself conflict.


Full commit log: v1.2.1...v1.3.0