> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-zh/chang-jing-sdk7/api-can-kao/version-support-agreement.md).

# 版本支持协议

版本支持协议

本文档描述了同时适用于 Creator Hub 中的 Scene Editor 和脚本框架（ `@dcl/sdk` 包）。

此版本控制策略的目标是为 Decentraland Foundation 的 SDK 团队与内容创作者建立一份契约，明确预期，并让内容创作者能够据此规划工作。

## 定义

* *版本号* ——一个公开可用的软件版本的唯一标识符。该标识符由一个 *主版本* 号和一个 *次版本* 号组成，以点分隔（例如，7.2）。
* *版本系列* ——所有主版本号相同的版本构成一个系列。若版本 A 与版本 B 属于同一系列，且 A 的次版本号高于 B，则称版本 A 是版本 B 的 *后继版本* 的后继版本（例如，7.11 是 7.10 的后继版本）。
* *破坏性变更* ——一种迫使用户修改其代码或资源以保持其正常运行的变更。例如，某个属性更名了，这会迫使用户在代码中每次使用该属性时都改成新的属性名。
* *非破坏性变更* ——一种不需要用户采取任何操作的变更。用户的代码和资源的行为与属性保持不变。
* *稳定版本* ——一种禁止其所有后继版本出现破坏性变更的版本（其所有后继版本也都被视为稳定版本）。任何破坏性变更都只能通过递增主版本号来创建新的版本系列引入；不过，请参见 [破坏性变更](#breaking-changes) 一节中的注意事项。非破坏性变更通过递增次版本号来体现。
* *不稳定版本* ——一种允许其后继版本出现破坏性变更的版本。破坏性变更可通过递增次版本号引入。

## 支持策略

在每个稳定版本系列中，Decentraland Foundation 只支持最新的次版本。任何时候最多只应有两个受支持的版本系列。

例如，如果 6.x 系列的最新次版本是 6.11，而 7.x 系列的最新次版本是 7.3，那么内容创作者应当在 6.11 或 7.3 上开发他们的场景。使用 6.10 或更早版本开发并发布的场景大概率仍可继续运行，玩家也能够继续享受它们。不过，如果这些较旧的场景出现任何问题，则必须先更新到受支持的版本，且只有当问题在受支持版本中仍然存在时才会进行调查。

Scene Editor 会自动更新同一版本系列中所有场景的脚本包，以便所有开发者在开发场景时都使用最新受支持版本。

## 功能开发

新功能只会发布到正在开发中的最新版本。一旦开发团队开始着手一个新的版本系列，仍处于支持期的较旧版本系列将只获得重大 bug 修复，不再实现任何额外功能。

## 破坏性变更

破坏性变更只应出现在主版本发布中。同一版本系列的稳定次版本发布中不应出现破坏性变更，除非在紧急情况下且没有其他办法处理。次版本发布中的破坏性变更是一种极端措施，开发者会不惜一切代价避免。新的次版本发布会扩展现有语法的能力，但除修复 bug 外，绝不应改变既有语法的输出。

### 独立变更

在极少数情况下，如果某个小范围、孤立的破坏性变更只会给一小部分用户带来不便，那么可能更适合这样做。（创建新的主版本会给所有用户带来不便。）在这种情况下，SDK 可能会弃用某个功能，但必须在合理期限内继续支持它。

### 紧急变更

在某些特殊情况下，例如安全问题或监管要求，任何功能都可能在不考虑其稳定级别的情况下以破坏性方式更改，并且在这些情况下不会承诺弃用期。

## 稳定发布与不稳定发布

### Alpha

每当引入新的主版本发布时，最初的几个次版本发布可能会被标记为不稳定 **透明度** 版本。Alpha 发布中必须允许并预期出现破坏性变更，用户也不应期待其稳定性。

开发者可以自由尝试这些 alpha 版本，但不鼓励使用不稳定的 alpha 版本发布内容，因为无法保证内容在后续变更后仍能正常运行。此时也不建议开始大规模且复杂的迁移，因为在下一个稳定发布之前可能还需要更多变更。

### Beta

当一个版本系列达到一定成熟度时，会提供一个 **beta** 版本发布。beta 发布被视为已完成，并在经过公开测试后即可宣布为稳定版。

Beta 版本系列应尽可能稳定；不过，允许其随着时间变化。这些变化应尽量少，但可以包含破坏性变更。破坏性变更只能在合理的弃用期之后引入，以便内容创作者有机会迁移其场景。此弃用期必须在引入破坏性变更时予以定义。

Beta 版本系列只应在 beta 阶段停留有限时间，具体时长在标记为 beta 时指定。如果在该期间未发现问题，就应提升为稳定版。该时间长度可按情况而异，但一个不错的经验法则是 90 天。

使用 beta 版本语法编写的内容，应当容易迁移到该系列中的后续版本。尽管如此，仍不建议使用 beta 版本为重大活动开发内容，因为测试仍在进行中，且很可能存在 bug。

### 稳定

如果 beta 期限结束且没有重大问题，该版本系列就被视为 **稳定的** ，语法不应再有进一步变更，除了新增功能。从此之后，该版本被视为所有开发者推荐并鼓励使用的选项。

稳定版本系列在其整个生命周期内必须获得全面支持。不得出现破坏性变更，但下文所述注意事项除外。

## 稳定发布中的不稳定功能

某次发布中的特定功能，其稳定级别可能与整个发布不同。这可能是因为该功能是近期引入的，需要更多测试；也可能是因为它很快就会被替换。

例如，在 SDK 框架已处于稳定的发布中，可以将一种新的组件类型以 alpha 形式引入，因为该特定组件可能仍需要独立的测试周期。之后它可以遵循上文所述的版本流程，从 alpha 到 beta，再到 stable。

稳定发布中的任何未被视为稳定的功能，都应在文档中明确标注。使用不稳定功能的创作者必须意识到，该功能可能会发生破坏性变更。任何破坏性变更都会清楚地传达，包括迁移指南，并且会提供一段过渡期，让创作者调整其场景代码。

## 我们会支持稳定版本系列多久？

一旦新的版本系列变为稳定版（7.x），团队承诺在前一个版本（6.x）上继续支持（重大 bug 修复）数个月，以便给创作者充足时间进行迁移。持续时间会根据所需的迁移工作量逐案决定。

## 预发布版本

始终可以通过安装 `@next` 的版本 `@dcl/sdk` 包到场景中，来访问脚本框架中的最新新增内容。

该分支中的功能可能不稳定或未记载，因为它们并非作为 SDK 官方支持版本的一部分发布。


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.decentraland.org/creator/content-creator-zh/chang-jing-sdk7/api-can-kao/version-support-agreement.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.