版本更新锁定问题

[NeverBehave]

目前的版本更新是直接推送到master，并同时生成新的docker镜像。这种滚动更新可以给用户带来最新的路由体验，但是也会造成一些可用性问题。

可能是时候需要重新引入一下版本号方便追求稳定的用户锁定可用版本和限制bug扩散范围

[github-actions]

👍 感谢提交该 Issue，请确保仔细阅读 Issue 模板，RSS 提案模板 或 Feature 提案模板 以便于测试。不符合模板将导致 Issue 被直接关闭。

👍 Thanks for the issue, please follow the Issue template, RSS proposal template or Feature proposal template. Otherwise the issue will be closed.

[fengkx]

https://github.com/fengkx/NodeRSSBot/blob/master/.github/workflows/dockerimage.yml#L21-L36 docker的版本可以考虑在GitHub action 中添加 Git hash 的 docker image tag。对非docker的手动部署似乎git本身就是一个很好的版本管理工具,我们只需要保证lock file中的版本对的上就好了？

RSSHub首页的debug信息里已经有7位的git hash, 或许在err的界面也应该加上

[NeverBehave]

git hash感觉不是很方便定位，如果按照release不容易产生大量零碎的版本
master始终滚动，然后每一个月左右产生一个release？

[fengkx]

用Git Hash的想法是鼓励用户用latest,并且提供一个出问题的时候回退的方法。这确实会产生大量零碎的版本。但我觉得一个月一次release对RSSHub来说太久了。

RSSHub的特点是依赖大量适配的路由（网站），而这些网站有可能会产生break change,导致路由失效要重新做适配。

打个比方豆瓣路由两天前修好了或者说新增了某个路由，相较于等比较长的一段时间release下一个版本，可能很多人会跑去用master分支。

上面这个特点让我想到了youtube-dl。或许我们可以借鉴一下用日期做版本号然后随缘release。

[Qeynos]

是否有可能分离成程序框架以及路由两部分内容，程序框架按计划release，路由信息按日期做版本号，可开启定期自动更新路由信息，就像rsshub radar，用户日常更新的数据量也有很大的优化

[NeverBehave]

用Git Hash的想法是鼓励用户用latest,并且提供一个出问题的时候回退的方法。这确实会产生大量零碎的版本。但我觉得一个月一次release对RSSHub来说太久了。

RSSHub的特点是依赖大量适配的路由（网站），而这些网站有可能会产生break change,导致路由失效要重新做适配。

打个比方豆瓣路由两天前修好了或者说新增了某个路由，相较于等比较长的一段时间release下一个版本，可能很多人会跑去用master分支。

上面这个特点让我想到了youtube-dl。或许我们可以借鉴一下用日期做版本号然后随缘release。

似乎可以，需要修订一下CI
也许 @SukkaW 有什么黑魔法

[NeverBehave]

是否有可能分离成程序框架以及路由两部分内容，程序框架按计划release，路由信息按日期做版本号，可开启定期自动更新路由信息，就像rsshub radar，用户日常更新的数据量也有很大的优化

这个的前提是 #6691 的确定，否则文档和route会有割裂
目前 @DIYgod 似乎确定了一个方向，我们等这个月过了看看进度

[queensferryme]

这个的前提是 #6691 的确定，否则文档和route会有割裂
目前 @DIYgod 似乎确定了一个方向，我们等这个月过了看看进度

如果这方面有进展了请 cc 我，我对这个话题比较感兴趣，愿意提供帮助重构。

[NeverBehave]

这个的前提是 #6691 的确定，否则文档和route会有割裂

目前 @DIYgod 似乎确定了一个方向，我们等这个月过了看看进度

如果这方面有进展了请 cc 我，我对这个话题比较感兴趣，愿意提供帮助重构。

@queensferryme 我和 @DIYgod 有讨论过了，我想在公开讨论方向前先私下有一些意见交换，如果你有空的话Telegram PM @NeverBehave我一下
其他有兴趣的开发者可以直接私聊我，或者邮件 github 邮箱