> 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-ko/sdk7/api/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는 동일한 버전 계열 내의 모든 씬에 대한 스크립팅 패키지를 자동으로 업데이트하므로, 모든 개발자가 씬을 개발할 때 최신 지원 버전을 사용하게 됩니다.

## 기능 개발

새 기능은 개발 중인 최신 버전에만 릴리스됩니다. 개발 팀이 새로운 버전 계열 작업을 시작하면, 계속 지원되는 이전 버전 계열에는 주요 버그 수정만 제공되며 추가 기능은 구현되지 않습니다.

## 호환성 깨짐 변경

호환성 깨짐 변경은 주 릴리스에서만 발생해야 합니다. 같은 버전 계열의 안정 부 릴리스 내에서는 호환성 깨짐 변경이 없어야 합니다. 단, 이를 해결할 다른 수단이 없는 긴급 상황은 예외입니다. 부 릴리스 내의 호환성 깨짐 변경은 개발자들이 어떤 대가를 치르더라도 피해야 하는 극단적인 조치입니다. 새 부 릴리스는 기존 구문이 만들어내는 결과를 변경해서는 안 되며, 버그 수정의 경우를 제외하고는 기존 구문의 기능만 확장해야 합니다.

### 고립된 변경

매우 드문 경우에는 소수의 사용자에게만 불편을 준다면 작고 고립된 호환성 깨짐 변경을 하는 편이 더 나을 수 있습니다. (새 주 버전을 만드는 것은 모든 사용자에게 불편을 줍니다.) 이 경우 SDK는 기능을 폐기(deprecate)할 수 있지만, 합리적인 기간 동안은 계속 지원해야 합니다.

### 긴급 변경

보안 문제나 규제 요구사항과 같은 특정 예외적 상황에서는 안정성 수준과 무관하게 어떤 기능이든 호환성 깨짐 방식으로 변경될 수 있으며, 이러한 상황에서는 폐기 안내가 약속되지 않습니다.

## 안정 및 비안정 릴리스

### 알파

새로운 주 릴리스가 도입될 때마다, 초기의 몇몇 부 릴리스는 비안정 **alpha** 버전으로 표시될 수 있습니다. 알파 릴리스에서는 호환성 깨짐 변경이 허용되고 예상되어야 하며, 사용자는 안정성을 기대해서는 안 됩니다.

개발자는 이 알파 버전으로 자유롭게 실험할 수 있지만, 불안정한 알파 버전으로 만든 콘텐츠를 배포하는 것은 권장되지 않습니다. 이후 변경으로 인해 해당 콘텐츠가 계속 작동한다는 보장이 없기 때문입니다. 또한 다음 안정 릴리스 전에 더 많은 변경이 필요할 수 있으므로, 이 시점에서 대규모의 복잡한 마이그레이션을 시작하는 것도 권장되지 않습니다.

### 베타

버전 계열이 일정 수준의 성숙도에 도달하면 **베타** 릴리스가 제공됩니다. 베타 릴리스는 공개 테스트를 거쳐 안정 버전으로 선언할 준비가 된 완성된 상태로 간주됩니다.

베타 버전 계열은 가능한 한 안정적이어야 합니다. 그러나 시간이 지나면서 변경될 수는 있습니다. 이러한 변경은 최소화되어야 하지만, 호환성 깨짐 변경이 포함될 수 있습니다. 호환성 깨짐 변경은 콘텐츠 제작자가 자신의 씬을 마이그레이션할 수 있도록 합리적인 폐기 기간이 지난 후에만 도입될 수 있습니다. 이 폐기 기간은 호환성 깨짐 변경이 도입될 때 정의되어야 합니다.

베타 버전 계열은 베타로 표시될 때 지정된 제한된 기간 동안만 베타 상태여야 합니다. 그 기간 동안 문제가 발견되지 않으면 안정 버전으로 승격되어야 합니다. 이 기간의 길이는 사례별로 다를 수 있지만, 일반적인 기준은 90일입니다.

베타 버전의 구문으로 작성된 콘텐츠는 해당 계열의 이후 버전으로 쉽게 마이그레이션할 수 있어야 합니다. 테스트가 아직 진행 중이고 버그가 발생할 가능성이 높으므로, 베타 버전으로 주요 이벤트용 콘텐츠를 개발하는 것은 여전히 바람직하지 않습니다.

### 안정

베타 기간이 종료될 때까지 큰 문제가 없으면, 해당 버전 계열은 **안정** 으로 간주되며, 새로운 기능이 추가되는 것 외에는 구문에 더 이상의 변경이 있어서는 안 됩니다. 이 시점부터 해당 버전은 모든 개발자가 사용하는 것이 권장되고 장려되는 옵션으로 간주됩니다.

안정 버전 계열은 수명 주기 동안 완전히 지원되어야 합니다. 아래에 설명된 주의 사항을 제외하고는 호환성 깨짐 변경이 있어서는 안 됩니다.

## 안정 릴리스 내의 비안정 기능

릴리스 내의 특정 기능은 릴리스 전체와는 다른 안정성 수준을 가질 수 있습니다. 이는 해당 기능이 최근에 도입되어 더 많은 테스트가 필요하기 때문일 수도 있고, 곧 대체될 예정이기 때문일 수도 있습니다.

예를 들어, SDK 프레임워크의 이미 안정적인 릴리스에 새로운 유형의 컴포넌트를 알파로 도입할 수 있습니다. 이 특정 컴포넌트는 아직 자체 테스트 주기가 필요할 수 있기 때문입니다. 그런 다음 위에서 설명한 버전 관리 흐름을 따라 알파에서 베타로, 다시 안정으로 진행할 수 있습니다.

안정 릴리스의 기능 중 안정적이지 않다고 간주되는 것은 문서에 그 사실이 명확히 표시되어야 합니다. 비안정 기능을 사용하는 제작자는 그 기능이 호환성 깨짐 변경을 겪을 수 있음을 인지해야 합니다. 모든 호환성 깨짐 변경은 마이그레이션 가이드를 포함하여 명확히 안내되며, 제작자가 씬의 코드를 조정할 전환 기간이 제공됩니다.

## 안정 버전 계열은 얼마나 오래 지원하나요?

새 버전 계열이 안정화(7.x)되면, 팀은 제작자들이 충분히 마이그레이션할 수 있도록 이전 버전(6.x)에 대해 몇 달간 지원(주요 버그 수정)을 약속합니다. 지원 기간은 필요한 마이그레이션 작업량에 따라 사례별로 결정됩니다.

## 사전 릴리스 버전

다음을 설치하면 스크립팅 프레임워크의 가장 최근 추가 사항에 항상 접근할 수 있습니다. `@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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-ko/sdk7/api/version-support-agreement.md?ask=<question>&goal=<user_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.