> For the complete documentation index, see [llms.txt](https://docs.docbits.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docbits.com/chinese/gai-shu-yu-ji-chu/docbits-release-lifecycle-strategy.md).
# DocBits 发布生命周期策略
\*\*NOVA R1.1 可用时间：\*\*自 **2026 年 10 月 16 日**起可在沙盒中使用。计划于 **2026 年 11 月 4 日**发布到生产环境。
随着即将推出的小版本 R1.1， DocBits 将采用新的发布生命周期策略，基于两个发布渠道：VESTA 和 NOVA。
**NOVA** 用于推出新的主版本和小版本，例如 **Rx** 和 **Rx.y**。**VESTA** 继续提供现有的生产版本。
## 发布渠道
| 渠道 | 在生命周期中的作用 |
| --------- | ----------------------------------------------------------------- |
| **VESTA** | 提供当前生产版本。 |
| **NOVA** | 提供下一个版本，并随其经历开发、测试和生产环境可用阶段而持续推进。在并行生产阶段，NOVA 和 VESTA 都提供可用的生产版本。 |
## 生命周期概览
每个周期包含三个阶段。随后由 FELLOWPRO 管理版本切换，将 NOVA 生产版本转入 VESTA，并开始下一个周期。
| 阶段 | VESTA | NOVA | 对贵组织的意义 |
| --------------- | ------------- | ------------------ | ---------------------------------------- |
| **1. 开发** | R1.0.x 在生产环境中 | R1.1 正在开发 | 在准备下一个版本期间，继续使用 VESTA。 |
| **2. QA 和验收测试** | R1.0.x 在生产环境中 | R1.1 正在进行 QA 和 UAT | 在 NOVA 沙盒中评估即将推出的版本，同时继续在 VESTA 上进行生产工作。 |
| **3. 并行生产** | R1.0.x 在生产环境中 | R1.1.x 在生产环境中 | 继续使用 VESTA，或在准备就绪时自行切换到 NOVA。 |
版本切换后，所有客户都将使用 VESTA R1.1.x，NOVA 则重新用于 R1.2 的开发。阶段 1 随更新后的版本号重新开始。
### 阶段 1 — 开发
VESTA 提供当前生产版本 R1.0.x，同时在 NOVA 中开发下一个版本 R1.1。在此阶段，贵组织继续在 VESTA 上开展日常工作。
### 阶段 2 — QA 和验收测试
即将推出的 NOVA 版本将进入质量保证 (QA) 和用户验收测试 (UAT) 阶段。您可以在 NOVA 沙盒中评估该版本，了解这些更改是否适合贵组织的工作流，并为采用新版本做好准备。
在此阶段，VESTA R1.0.x 仍是生产版本。进入阶段 3 并可用后，您即可切换到 NOVA 用于生产。
### 阶段 3 — 并行生产
VESTA R1.0.x 和 NOVA R1.1.x 都是可用的生产版本。贵组织可根据自身需求和沙盒评估结果，决定是否以及何时切换到 NOVA。
要在此阶段采用 NOVA：
1. 在 NOVA 沙盒中评估该版本。
2. 查看发布公告，或联系 FELLOWPRO Support，确认两个生产环境均已准备就绪并可供切换。
3. 决定贵组织何时准备好在生产环境中使用新版本。
4. 在 DocBits 中，前往 **Settings > Company Information > Release Channel** 并选择 **NOVA**。
在并行生产期间，您也可以前往 **Settings > Company Information > Release Channel** 并选择 **VESTA**，切换回 VESTA。
渠道切换由客户自行操作。FELLOWPRO 不会为客户选择是否切换到 NOVA。在整个并行生产期间，您都可以继续使用 VESTA，并在后续版本切换时采用新版本。
## 发布版本切换和下一个周期
当 NOVA 版本已准备好成为通用生产版本，并且已获得所有客户对计划转换的接受后，FELLOWPRO 将管理版本切换：
**NOVA R1.1.x → VESTA R1.1.x**
### 提前公告并征求客户接受
FELLOWPRO 会提前通过电子邮件向所有客户公告计划中的版本切换，并征求他们对该转换的接受。欢迎您联系 FELLOWPRO，提出任何疑虑或异议，以便在版本切换前进行讨论。只有在版本准备就绪且所有客户都接受计划中的转换后，才会执行版本切换并重新启用 NOVA。
### 版本切换时的变化
| 变化 | 结果 |
| ---------------------- | ---------------------------------- |
| **NOVA 版本成为 VESTA 版本** | R1.1.x 成为 VESTA 中所有客户共用的生产版本。 |
| **上一版本退役** | R1.0.x 将被停用，无法再通过任何一个渠道或其他方式使用。 |
| **NOVA 重新用于下一个版本** | R1.2 开始在 NOVA 中开发，下一个周期的阶段 1 随之开始。 |
之后，同样的三个阶段将以新的版本号重复进行。
下图更详细地展示了上述发布周期。
### 发布节奏
通过 NOVA 推出的主版本和小版本，与应用于 VESTA 和 NOVA 生产版本的热修复，计划节奏有所不同。
#### 通过 NOVA 推出主版本和小版本
FELLOWPRO 目前计划，**通过 NOVA 发布渠道推出主版本和小版本（例如 Rx 和 Rx.y）的周期约为 3–4 个月**。此估算适用于上述发布生命周期，包括随后切换到 VESTA 并将 NOVA 重新用于下一个版本。它不代表热修复的频率。
此周期是我们当前的计划估算；它不是固定日程、周期时长上限，也不构成发布或版本切换日期的保证。每次版本切换和 NOVA 重新启用的时间，取决于**版本是否准备就绪以及所有客户是否接受计划中的转换**。如果需要更多时间来确保版本准备就绪、处理客户疑虑或获得每位客户的接受，周期就会延长，可能超过四个月。
FELLOWPRO 会提前通知每次计划中的版本切换。任何预估时间都以满足上述条件为前提。
#### VESTA 生产环境中的热修复
VESTA 生产版本预计**大约每月发布一次热修复，或以稍长的间隔发布**。这是参考节奏，而非固定日程或保证的交付日期。
#### NOVA 生产环境中的稳定性热修复
无法为 NOVA 生产环境中的稳定性热修复指定通用节奏。NOVA 会推出全新的版本，因此此类热修复的时间和频率取决于特定版本的稳定性需求。因此，它们不会遵循 VESTA 的参考月度节奏，也不会遵循主版本和小版本的 3–4 个月周期。
## 职责和客户选择
| 转换 | 管理方 | 预期事项 |
| ---------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------- |
| **在阶段 3 于 VESTA 和 NOVA 之间切换** | 贵组织 | 在沙盒中评估 NOVA，并选择是否以及何时切换。在并行生产期间，通过 **Settings > Company Information > Release Channel** 选择 NOVA，或切换回 VESTA。 |
| **将 NOVA R1.1.x 切换为 VESTA R1.1.x** | FELLOWPRO | 查看提前发送的电子邮件公告，提出任何疑虑或异议，并确认接受计划中的转换。版本准备就绪且所有客户都已接受后，FELLOWPRO 才会继续执行。 |
## 重要提示：切换前请检查环境是否可用
仅当 VESTA 和 NOVA 上的**对应环境**均有并行版本可用且已准备就绪时，才可通过 **Settings > Company Information > Release Channel** 在两个渠道之间切换。沙盒和生产环境的可用情况必须分别评估：
* \*\*沙盒：\*\*当新版本已准备就绪并可在 NOVA 沙盒中使用，且 VESTA 沙盒仍可用时，您即可从 VESTA Sandbox 切换到 NOVA Sandbox。切换回来时也必须满足相同的准备就绪要求。
* \*\*生产环境：\*\*只有当两个生产版本都已准备就绪并可并行使用时，您才可以在 VESTA Production 和 NOVA Production 之间切换。NOVA 沙盒可用并不意味着 NOVA Production 已准备好供您使用。
如果对应环境尚未准备就绪或不可用时进行切换，可能会影响您的运营。FELLOWPRO 会在版本即将在沙盒或生产环境中可用的几天前发送发布公告电子邮件。请在切换前查看这些公告。如果您不确定是否可以切换，或此切换是否适合贵组织，请联系 FELLOWPRO Support 确认。
\*\*计划中的可用性控制：\*\*FELLOWPRO 正在开发一个 Yes/No 控制项，让 Support 能够将 Release Channel 设置设为只读，或独立于软件部署启用渠道切换。此控制项推出后，Support 将在对应环境准备就绪时启用切换，否则将设置保持为只读。该控制项旨在让客户能够在设置启用时安全地在 VESTA 和 NOVA 之间切换。在此控制项推出之前，即使设置可编辑，也不应将其视为适合切换的确认；请遵循发布公告，或向 Support 确认。
## 常见问题
### 如何确认在 VESTA 和 NOVA 之间切换是否安全？
请查看您打算使用的环境对应的发布公告，或咨询 FELLOWPRO Support，确认是否适合切换。两个对应环境必须都已准备就绪并可并行使用；沙盒已准备就绪并不代表生产环境也已准备就绪。有关完整指导，包括用于启用或禁用渠道切换的计划控制项，请参阅上文的[重要提示：切换前请检查环境是否可用](#important-check-environment-availability-before-switching)。
### NOVA 在生产环境中可用时，我们可以继续使用 VESTA 吗？
可以。在阶段 3，您可以继续使用 VESTA，也可以在贵组织准备就绪时切换到 NOVA。在随后的版本切换中，新版本将成为 VESTA 版本，上一版本则会退役。
### 如何切换到 NOVA 或切回 VESTA？
首先，请按照[切换前请检查环境是否可用](#important-check-environment-availability-before-switching)中的说明，确认两个渠道上的对应环境均已准备就绪并可用。沙盒和生产环境的可用情况需要分别确认。
在阶段 3，于 DocBits 中前往 **Settings > Company Information > Release Channel**，选择 **NOVA** 以采用新的生产版本，或选择 **VESTA** 以返回当前的 VESTA 生产版本。贵组织可根据自身需求和对 NOVA 的沙盒评估结果独立做出选择。该选择仅在两个版本并行可用期间有效；VESTA 上的上一版本会在版本切换时退役。
### NOVA 何时可用于生产？
NOVA 在阶段 3 成为可用的生产版本，此前需经历开发和 QA/UAT。在此阶段，VESTA 和 NOVA 以不同的软件版本并行运行于生产环境中。
### 我们如何得知版本切换安排？可以提出异议吗？
FELLOWPRO 会提前通过电子邮件联系所有客户，并征求他们对计划中转换的接受。欢迎您向 FELLOWPRO 提出任何疑虑或异议。只有在版本准备就绪且获得所有客户接受后，才会执行版本切换并重新启用 NOVA。
### 版本切换后，我们还能继续使用 R1.0.x 吗？
不能。R1.0.x 会在版本切换时停用，无法再通过任何一个渠道或其他方式使用。R1.1.x 将成为所有客户共用的 VESTA 生产版本。
### 版本切换与我们切换到 NOVA 有什么不同？
您在阶段 3 自行切换到 NOVA，是在自行决定何时采用新的生产版本。版本切换则是之后由 FELLOWPRO 管理的转换：NOVA R1.1.x 成为 VESTA R1.1.x，上一版本退役，下一个周期开始。
### 版本切换后 NOVA 会怎样？
NOVA 将重新用于下一个版本的开发，本例中为 R1.2。VESTA 提供 R1.1.x，同时 NOVA 再次经历开发、QA/UAT 和并行生产阶段。
### 是否保证每三到四个月推出一个主版本或小版本？
不能保证。通过 NOVA 推出主版本和小版本的约 3–4 个月节奏，是当前的计划估算，并非保证的日程或周期时长上限。切换版本并重新启用 NOVA，既要求版本准备就绪，也要求所有客户接受。如果满足任一条件需要更多时间，周期就会延长，可能超过四个月。FELLOWPRO 会提前通知每次计划中的版本切换。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.docbits.com/chinese/gai-shu-yu-ji-chu/docbits-release-lifecycle-strategy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.