> 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 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-ko/sdk7/api/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.