#16 moves the reading-position store out of extensions.zotero.zotero-tts.readAloud.positions and into the plugin's own SQLite database. Copies upgrading from 1.9.x or earlier still have their bookmarks in that pref, so the store imports it inside open() (src/read-aloud/position-store.ts): every entry is normalized on the way in (pre-#14 entries can carry a full rect list) and written with a plain REPLACE INTO positions — no ts comparison, since downgrade round-trips are out of consideration (settled 2026-08-31, on #16) — and the pref is cleared only after the insert transaction commits, so a mid-import failure retries on the next start. The import is self-clearing: from the second startup on it costs one prefs.get that returns undefined and one no-op prefs.clear.
Cost is not the reason to remove it. It is that a function which parses a format nothing writes any more turns into code nobody is sure it is safe to delete. So the deletion condition is fixed now, here and in the import block's own comment in position-store.ts, rather than left to whoever reads it in a year.
Delete in 2.0.0:
- the
legacy dep and the import block inside open() in src/read-aloud/position-store.ts
readPositions() and READ_ALOUD_POSITIONS_PREF in src/read-aloud/read-aloud-position.ts- in
src/index.ts: the legacy wiring, the open-failure fallback (initial = readPositions(prefs), which becomes []), and the diagnostics legacyPref field
- the tests that pin them: the
readPositions suite in test/read-aloud/read-aloud-position.test.ts and the import/clear cases in test/read-aloud/position-store.test.ts
Who loses bookmarks when it goes: everyone still on ≤1.9.x when 2.0.0 ships. update.json always points at the latest release only, so those copies jump straight to 2.0 and never run the import — the default fate of any copy that did not happen to update during the 1.10→1.x window, not an edge case, and 2.0's release notes are written for that audience. The loss is the bookmarks alone — listening to those documents again re-creates them. No setting and no key is affected, and the store has never been part of DEFAULTS, so the settings backup never carried it either.
#16 moves the reading-position store out of
extensions.zotero.zotero-tts.readAloud.positionsand into the plugin's own SQLite database. Copies upgrading from 1.9.x or earlier still have their bookmarks in that pref, so the store imports it insideopen()(src/read-aloud/position-store.ts): every entry is normalized on the way in (pre-#14 entries can carry a full rect list) and written with a plainREPLACE INTO positions— notscomparison, since downgrade round-trips are out of consideration (settled 2026-08-31, on #16) — and the pref is cleared only after the insert transaction commits, so a mid-import failure retries on the next start. The import is self-clearing: from the second startup on it costs oneprefs.getthat returnsundefinedand one no-opprefs.clear.Cost is not the reason to remove it. It is that a function which parses a format nothing writes any more turns into code nobody is sure it is safe to delete. So the deletion condition is fixed now, here and in the import block's own comment in
position-store.ts, rather than left to whoever reads it in a year.Delete in 2.0.0:
legacydep and the import block insideopen()insrc/read-aloud/position-store.tsreadPositions()andREAD_ALOUD_POSITIONS_PREFinsrc/read-aloud/read-aloud-position.tssrc/index.ts: thelegacywiring, the open-failure fallback (initial = readPositions(prefs), which becomes[]), and the diagnosticslegacyPreffieldreadPositionssuite intest/read-aloud/read-aloud-position.test.tsand the import/clear cases intest/read-aloud/position-store.test.tsWho loses bookmarks when it goes: everyone still on ≤1.9.x when 2.0.0 ships.
update.jsonalways points at the latest release only, so those copies jump straight to 2.0 and never run the import — the default fate of any copy that did not happen to update during the 1.10→1.x window, not an edge case, and 2.0's release notes are written for that audience. The loss is the bookmarks alone — listening to those documents again re-creates them. No setting and no key is affected, and the store has never been part ofDEFAULTS, so the settings backup never carried it either.