Confirm whether an installed `.deb` auto-updates, and document the answer
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 65/100
- Issue 类型
- 文档
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- electron, linux
- 领域
- desktop, documentation
调研方向
Read docs/architecture/updates.md, ADR 0020, and surfsense_local/electron/src/main/updater.ts; inspect resources/package-type in an installed v2.0.2 .deb. On an x64 Linux desktop, allow updates in Settings › About, record whether 2.0.3 is offered, downloads, and installs on restart, and attach the session log with your distribution and version. Replace the table's likelihood and remove the Known gaps line; if a code or configuration change proves necessary, use updater.test.ts and run pnpm test.
由索引模型根据 Issue 内容生成。
描述
The gap
docs/architecture/updates.md lists this under Known gaps:
The deb build likely auto-updates, although the launch plan said it would not: electron-builder writes
resources/package-typefor a deb, electron-updater picks its deb updater from that file, and v2.0.2'sstable-linux.ymlon the release listsSurfSense.deb. Not checked on an installed deb.
Why it matters
The doc's release table currently says "likely the deb", and the launch plan said the deb would not update itself. Both cannot be true, and it is deb users who find out which. If it does update, someone who installed through their package manager gets an application that replaces itself outside it, and that deserves to be stated plainly rather than discovered. If it does not, stable-linux.yml advertises an asset no client can use and every deb user is quietly stuck on the version they installed, with the update row in Settings telling them nothing useful.
This is checkable now without cutting anything: v2.0.2 and v2.0.3 are both published, so an installed 2.0.2 deb has a newer release to find.
Where
surfsense_local/electron/electron-builder.yml—linux.target: [AppImage, deb]andpublish.channel: stable, which is what makes the app readstable-linux.yml.surfsense_local/electron/src/main/updater.ts— how the app configures electron-updater, includingautoDownloadbeing false, so nothing happens until the user allows it.electron-updateris pinned at^6.8.9insurfsense_local/electron/package.json. Its choice of updater fromresources/package-typeis the behaviour under test.docs/architecture/updates.md— the "What a release carries" table'slikely the deb (Known gaps)cell is what your answer replaces.
What done looks like
- A report on an x64 Linux desktop: install the published v2.0.2
.deb, allow updates in Settings › About, and say what happened — whether 2.0.3 was offered, whether it downloaded, and whether the restart action installed it. resources/package-typeinside the installed app is named as present or absent, with its contents. That file is the whole mechanism, so it is the first thing to look at and the cheapest half of the answer.- The doc's table cell states the answer rather than a likelihood, and the Known gaps line is gone.
- Your environment is in the issue: distribution and version, and whether this was a real desktop session or a container. The answer may not be the same everywhere, and the next reader needs to know what was tested.
- If it does update in a way that leaves the package manager's database stale, say so in the doc. Whether that needs fixing is a separate issue, not this one.
What not to change
Do not change publish.channel or allowPrerelease to make testing easier. The channel names are the only thing keeping 2.x manifests away from the legacy 0.0.x clients, and updater.ts records that dropping allowPrerelease changes behaviour for shipped clients and has to ship on its own.
How to verify
This one is answered by observation, so the report is the deliverable — attach the app's own session log from the update attempt. There is no existing test for it, and the honest thing is not to invent one against a released binary. If the answer turns out to need a code or configuration change, that change is TDD like any other: write its failing test first, in surfsense_local/electron/src/main/updater.test.ts, which already drives the updater.
python scripts/check_docs.py # from the repo root, for the doc edit
cd surfsense_local/electron && pnpm test
Before you start
Read CONTRIBUTING.md, the updates doc and ADR 0020. Open your PR against dev, not main. Comment here to claim this, and say which distribution you can test on.
- 主要语言
- Python
- 星标
- 16.3k
- 派生
- 1.6k
- 平均合并
- 12 小时 13 分钟
- 30 天内合并 PR
- 274
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
MODSetter/SurfSense 的其他 Issue
-
Security Scan: stop flagging pinned hashes and test fixtures on release PRs可能已有人在做 @karthikeya1220 今天认领。 未关闭code quality security
难度 2/5 1-3 小时 新手友好度 78/100
MODSetter/SurfSense#2225 · 1 条评论 ·
维护者通常 1 天内回复
-
Check Apple notarization credentials on dry runs and weekly可能已有人在做 @Cedric921 今天认领。 未关闭desktop
难度 2/5 1-3 小时 新手友好度 72/100
MODSetter/SurfSense#2224 · 1 条评论 ·
维护者通常 1 天内回复
-
Release workflow: keep the macOS certificate off the Windows dry-run build可能已有人在做 @Cedric921 今天认领。 未关闭desktop security
难度 2/5 1-3 小时 新手友好度 78/100
MODSetter/SurfSense#2223 · 1 条评论 ·
维护者通常 1 天内回复
-
Write the ADR for chat modes可能已有人在做 @Cedric921 今天认领。 未关闭architecture desktop documentation
难度 2/5 1-3 小时 新手友好度 75/100
MODSetter/SurfSense#2220 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
维护者通常 1 天内回复
查看 MODSetter/SurfSense 的全部 Issue
相似的 Issue
-
approved Good First Issue scope: docs
难度 1/5 1 小时以内 新手友好度 85/100
hiero-ledger/hiero-sdk-python#2730 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
wemake-services/wemake-django-template#3178 · 1 个 reaction ·
维护者通常 1 天内回复
-
md/asciidoc/csv: an explicit `encoding="utf-8"` keeps a leading BOM, the auto-detect path drops it未关闭
难度 2/5 1-3 小时 新手友好度 82/100
docling-project/docling#4846 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
neurostuff/NiMARE#1181 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
pytest-dev/pytest#15180 ·
维护者通常 1 天内回复