-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
What feature is it?
采用基于日期的版本号发布 GitHub Release
Adopt CalVer for GitHub Releases
建议在每次 Docker 镜像构建成功后,通过 GitHub Action 自动创建一个对应日期的 Git Tag(例如 v2026.02.20)。
We suggest using GitHub Actions to automatically create a date-based Git Tag (e.g., v2026.02.20) whenever a Docker image is successfully built.
What problem does this feature solve?
目前 RSSHub 采用滚动更新模式,虽然非常灵活,但给下游软件包(Downstream Packaging)的维护带来了巨大挑战。
Currently, RSSHub follows a rolling release model. While flexible, it creates significant challenges for downstream package maintenance.
-
Docker 与 GitHub 仓库不一致 (Inconsistency between Docker and GitHub)
目前 RSSHub Docker Hub 1 已经按照日期发布 Tags,但 GitHub 仓库本身并没有对应的 Git Tags。这导致用户很难溯源某个 Docker 镜像对应的具体源码状态。
Docker images are already tagged by date, but the GitHub repository lacks corresponding Git Tags. This makes it difficult to trace a specific Docker image back to its exact source code state. -
Nix 与 AUR 构建频繁失效 (Broken Nix and AUR builds)
在 Nix 生态中,flake.nix依赖pnpmDeps的固定哈希(fixed-output hash)。由于项目频繁更新pnpm-lock.yaml却不同步更新flake.nix中的sha256,导致 Nix 构建几乎一直处于不可用状态。
In the Nix ecosystem,flake.nixrelies on a fixed-output hash forpnpmDeps. Becausepnpm-lock.yamlis updated frequently without updating thesha256inflake.nix, the Nix build is almost constantly broken. -
定义与实现脱节 (Mismatch between definition and implementation)
现在的 Nix 和 AUR 软件包定义无法与项目的具体实现版本一一对应。缺乏稳定的 Release 锚点,维护者只能被迫指向master分支,这完全违背了可重现构建(Reproducible Builds)的原则。
Current package definitions for Nix and AUR cannot map to a specific implementation. Without stable release anchors, maintainers are forced to track themasterbranch, which violates the principles of Reproducible Builds.
Additional description
No response
This is not a duplicated feature request or new RSS proposal
- I have searched existing issues to ensure this feature has not already been requested and this is not a new RSS proposal.