[Request] 对于版本发布的一些建议

[Yerosius]

🥰 需求描述

如题，目前对于版本发布的情况比较混乱，造成了每天会发布多次新版本，频繁提示更新的现象(少则每天五六次，多至十到二十次)

🧐 解决方案

希望当正式推出1.0版本后能将产品版本号细分：
主版本号.小版本号.补丁版本号
将版本发布分为以下几个频道：
1.Nightly频道：Alpha版 ，用于接收补丁版本的非紧急安全问题的小修小补，并且接收夜间构建版本。此版本更新最频繁，同时也最不稳定，可能遇到各种莫名其妙的bug，不允许实际生产环境中部署。
2.Dev频道：Beta版，每个小周期(比如一周)积累下的Alpha版本的合集，用于推送给Beta版本，更新频率较为频繁，稳定性较差，不建议用于实际生产环境。
3.Preview频道：RC版，每个大周期(如半个月/一个月)接受一次版本更新，用于积累Beta版本的合集，更新频率适中，稳定性一般，可考虑但仍不推荐用于实际生产环境。
4.Stable频道：默认部署版本，每个完整周期接收一次版本更新，是最稳定的版本，更新频率低，但每次更新都会有较大改变。稳定性最强，也是部署的默认版本。

📝 补充信息

No response

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

🥰 Description of requirements

As the title states, the current version release situation is relatively confusing, resulting in new versions being released multiple times a day and prompting for updates frequently (as few as five or six times a day, and as many as ten to twenty times).

🧐 Solution

We hope that when version 1.0 is officially launched, the product version number can be subdivided:
Major version number. Minor version number. Patch version number
Divide version releases into the following channels:
1.Nightly channel: Alpha version, used to receive patch versions of minor fixes for non-urgent security issues, and to receive nightly builds. This version is updated most frequently and is also the most unstable. It may encounter various inexplicable bugs and is not allowed to be deployed in actual production environments.
2.Dev channel: Beta version, a collection of Alpha versions accumulated in each small cycle (such as a week), used to push to the Beta version, the update frequency is more frequent, the stability is poor, not recommended for actual use Production Environment.
3. Preview channel: RC version, which receives a version update every big cycle (such as half a month/month) and is used to accumulate a collection of Beta versions. The update frequency is moderate and the stability is average. It can be considered but is still not recommended. Actual production environment.
4.Stable channel: The default deployment version receives a version update every full cycle. It is the most stable version with low update frequency, but there will be major changes in each update. It is the most stable and is also the default version deployed.

📝 Supplementary information

No response

[lobehubbot]

👀 @Yerosius

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.
非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[1PercentSync]

不建议，现在无论是模型服务还是lobe本身的功能开发都在频繁变化，开多个频道管理难度显著上升，实际上目前推送的版本一般都比较稳定，所谓nightly就是源码本身，完全可以自己编译。让更多的用户参与到前沿的测试也是有利于项目改进。
更新提示不代表一定要更新，如果实在强迫症也可以自行修改屏蔽，固定一个你认为稳定的版本或者延迟更新。
或者增加自动检测新版本的频率，在看到之前自动更新部署。
对于有时候提示更新但实际上没有发版的情况确实可以改善。或者内置的提示更新在发版延迟半小时之后。
通常部署在vercel的已经自动同步完了，就不会看到更新提示。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Not recommended. Now both the model service and the function development of the lobe itself are changing frequently, and the difficulty of managing multiple channels has increased significantly. In fact, the versions currently pushed are generally relatively stable. The so-called nightly is the source code itself, which can be compiled by yourself. . Allowing more users to participate in cutting-edge testing is also conducive to project improvement.
The update prompt does not mean that you must update. If you are really obsessive-compulsive, you can modify the shield yourself, fix a version you think is stable, or delay the update.
Or increase the frequency with which new versions are automatically detected, automatically updating deployments before they are seen.
It can really be improved on the situation where updates are sometimes prompted but no version is actually released. Or the built-in prompt is updated after the release is delayed for half an hour.
Usually the ones deployed in vercel have been automatically synchronized and you will not see the update prompt.

[arvinxx]

频繁提示更新的现象(少则每天五六次，多至十到二十次)

我检查过应该不存在一天十几二十次 ，不信你可以检查下这个列表： https://npmmirror.com/package/@lobehub/chat/versions ，没有哪天是发版是超过 10 次的。

目前对于版本发布的情况比较混乱，造成了每天会发布多次新版本
希望当正式推出1.0版本后能将产品版本号细分：
主版本号.小版本号.补丁版本号

我们现在的发版逻辑就是严格遵循 SemVer [主版本号.小版本号.补丁版本号] 这个逻辑的，只是我没有专门说明而已。

小版本号的发布逻辑是特性更新，例如：

• 发布一个新的 provider， 例如 Together AI：✨ feat: Support TogetherAI as new model provider #1709
• 新增一个 feature ，如云同步： ✨ feat: support sync data between different device #1525
• 新增一个语言， 例如最近新增的保加利亚语：✨ feat: add Bulgarian translation #1732

小版本号的发布逻辑是 问题修复，例如：

• 修正一个 model id 的问题： 🐛 fix: fix google ultra model name #1813
• 修正用户反馈的缺陷：[Bug] 使用“添加助手并会话”不会跳转到会话那里 #1784
• 优化性能：⚡️ perf: refactor layout implements to improve performance #1736
• 代码重构：♻️ refactor: refactor the Vercel Aanlytics and support Google Aanlytics #1688

其他关于文档更新、添加测试、项目配置变更、ci/cd workflow 等则不会自动触发版本发布。

以上是关于目前使用的发布流程的规则介绍。同时我们采用了 Semantic Release 将发版过程和 docker build 过程自动化，保证每个版本的发布不需要人工参与。

---

将版本发布分为以下几个频道：

这个问题我之前讨论过，最后决定不采用 nightly/dev/stable 这种多频道划分的开发模式，仍然按照现有的发版模式来运作。考虑原因如下：

我们没有下游依赖方

多频道开发一般用于基础设施层，例如 node、 nextjs、 redis 等等，基础设施的频繁发版对于下游依赖方的体验就会很差，而且的确可能造成不稳定。但LobeChat 是一个面向终端用户的产品应用，不是上面提到的研发基础设施，没有谁是需要依赖 LobeChat 的，因此不存在频繁发版导致下游依赖方的不稳定的问题 ；（二开不在我们考虑范畴内，商业授权的客户会给专门的解决方案）

确保更快速的交付与用户反馈

搞 stable 这种非常像在憋大招，但搞不好可能憋出来的大招耗费心力又社区不讨好。但现在采用的模式每个 PR 在合并后就直接 ship 到用户手上，并能非常快速地获得第一手反馈。我之前试过憋 Midjourney 插件 这种大招，但是最后发现 ROI 并不理想，还是先发布了一个小的版本，所以未来绝对不会再去轻易尝试憋大招的开发模式了。

社区可以参与做更全面的测试

我们没有所谓的专职测试人员，因此只能借助社区的力量来帮我们发现代码中的实现问题，切到 nightly/dev/stable 这种模式下只会导致测试不充分不全面，很容易出现发布 stable 之后又补各种 hotfix，那么这个分频道意义又降低了。

我们倾向不锁依赖的版本开发模式

不锁版本意味着我们的每次构建都是采用最新的社区依赖，潜在漏洞问题都会在无感知的情况下自动修复。而 stable 模式下必然要采取锁版本。这个时候很有可能出现在每次需要升级依赖的时候升不上去的问题。

在不锁版本的情况下，哪个版本有问题我们可以在第一时间立刻感知到（例如 [email protected]~1.0.33 的安装 bug ，next-auth 某个版本的 bug ），并且可以及时向上游依赖方反馈。这是我们认为比较好的与社区共同发展的模式。

确保代码质量的稳固提升

敢于每天几个版本这种发布的底气在于，我针对核心业务逻辑实现了 90% 以上的单测覆盖 （在 AI 的帮助下）。因此只要单测能跑过就可以确保 chat 的核心功能不会出现问题。 这是我们可以达到现在这样快速迭代的核心因素。

也正是如此，我可以非常自信地在任何时候实施 因历史局限性出现的不合理代码 的重构与发布，并快速进入下一个迭代。如果有了一个 stable ，可能这种动核心框架的代码重构只能在大版本中出现，而最终的结局很可能就是变成一 💩 山，维护不动。

与社区更好的互动

现在的这种模式可以确保任何合理的诉求，在我觉得做起来简单，而且有时间的情况下，可以在非常短的时间内上线。

比如 Moonshot 的 Provider 集成就是这样。在我刚发布完第一批 Providers 接入版本的那天下午，他们宣布开放了 API，然后我晚上1小时就完成了整个接入，并发布了新版本。

我已经遇到了好多次用户问什么时候能发布，我跟他回答说你问我的前几分钟刚刚发版。作为用户，谁不希望早上提出的需求，下午就能上线的呢？

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Frequent update prompts (as few as five or six times a day, and as many as ten to twenty times)

I've checked that there shouldn't be more than ten or twenty times a day. If you don't believe it, you can check this list: https://npmmirror.com/package/@lobehub/chat/versions. There is no day where there are more than 10 releases.

The current version release situation is relatively confusing, resulting in new versions being released multiple times every day.
We hope that when version 1.0 is officially launched, the product version number can be subdivided:
Major version number.Minor version number.Patch version number

Our current release logic strictly follows the logic of SemVer [major version number. minor version number. patch version number], but I did not explain it specifically.

The release logic of minor version numbers is Feature Update, for example:

• Release a new provider, such as Together AI: ✨ feat: Support TogetherAI as new model provider #1709
• Add a new feature, such as cloud synchronization: ✨ feat: support sync data between different device #1525
• Add a new language, such as the recently added Bulgarian: ✨ feat: add Bulgarian translation #1732

The release logic of minor version numbers is problem fix, for example:

• Fixed a model id problem: 🐛 fix: fix google ultra model name #1813
• Fixed defects reported by users: [Bug] 使用“添加助手并会话”不会跳转到会话那里 #1784
• Optimize performance: ⚡️ perf: refactor layout implements to improve performance #1736
• Code refactoring: ♻️ refactor: refactor the Vercel Aanlytics and support Google Aanlytics #1688

Other documents updates, adding tests, project configuration changes, ci/cd workflow, etc. will not automatically trigger version releases.

The above is an introduction to the rules of the publishing process currently used. At the same time, we use Semantic Release to automate the release process and docker build process to ensure that the release of each version does not require manual participation.

---

Divide version releases into the following channels:

I have discussed this issue before, and finally decided not to adopt the multi-channel development model of nightly/dev/stable, and still operate according to the existing release model. Consider the following reasons:

We have no downstream relying parties:

Multi-channel development is generally used in the infrastructure layer, such as node, nextjs, redis, etc. Frequent releases of infrastructure will have a poor experience for downstream relying parties, and may indeed cause instability. But LobeChat is a product application for end users, not the R&D infrastructure mentioned above. No one needs to rely on LobeChat, so there is no problem of frequent releases causing instability to downstream relying parties; (2) Opening is not within our scope of consideration, commercially authorized customers will provide specialized solutions)

Ensure faster delivery and user feedback:

Building a stable game is very much like holding back a big move, but if you don't hold it in, the big move that comes out may be very labor-intensive and unpopular with the community. But in the current model, each PR is shipped directly to the user after being merged, and first-hand feedback can be obtained very quickly. I tried the big trick of holding back Midjourney plug-in before, but in the end I found that the ROI was not ideal, so I released a small version first. Therefore, I will never try the development model of holding back the ultimate move easily in the future.

The community can participate in more comprehensive testing

We do not have so-called full-time testers, so we can only use the power of the community to help us find implementation problems in the code. Switching to nightly/dev/stable will only lead to insufficient and incomplete testing, and it is easy to release stable Afterwards, various hotfixes were added, so the significance of this sub-channel was reduced again.

We prefer a version development model that does not lock dependencies

Unlocked versions mean that each of our builds uses the latest community dependencies, and potential vulnerabilities will be automatically fixed without any awareness. In stable mode, the version must be locked, and it is very likely that the dependencies will not be upgraded every time.

Without locking the version, we can immediately detect which version has a problem (for example, [[email protected]~1.0.33 installation bug](https://github.com/oven-sh/ bun/issues/9503), bug in a certain version of next-auth), and can provide timely feedback to the upstream relying parties. This is what we think is a better model of joint development with the community.

Ensure a solid improvement in code quality

The confidence that I dare to release several versions every day is that I have achieved more than 90% single test coverage for the core business logic (https://app.codecov.io/gh/lobehub/lobe-chat) (in AI with the help of). Therefore, as long as the single test can be run, it can be ensured that there will be no problems with the core functions of chat. This is the core factor that allows us to iterate as quickly as we do now.

This is why I can refactor and release unreasonable code due to historical limitations with great confidence at any time. and move quickly to the next iteration. If there is a stable, this kind of code refactoring that changes the core framework may only appear in major versions, and the final outcome is likely to become a mountain without maintenance.

Better interaction with the community

The current model can ensure that any reasonable appeal can be put online in a very short time if I think it is easy to do and have time.

For example, Moonshot's Provider integration is like this. In the afternoon after I released the first batch of Providers access versions, they announced that they had opened the API, and then I completed the entire access in one hour at night and released the new version.

I have met many times when users have asked when it will be released. I replied that it was just released a few minutes before you asked me. As a user, who doesn’t want the requests made in the morning to be online in the afternoon?

[lobehubbot]

✅ @Yerosius

This issue is closed, If you have any questions, you can comment and reply.
此问题已经关闭。如果您有任何问题，可以留言并回复。