Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Godot 출시 정책
Godot의 출시 정책은 지속적으로 발전하고 있습니다. 아래에 설명된 내용은 예상되는 사항에 대한 일반적인 아이디어를 제공하기 위한 것이지만 실제로 일어날 일은 핵심 기여자의 선택과 주어진 시간에 커뮤니티의 요구 사항에 따라 다릅니다.
Godot 버전 관리
Godot는 메이저(major).마이너(minor).패치(patch) 버전 시스템을 사용하여 Semantic Versioning를 느슨하게 따르지만, 각 용어의 해석은 게임 엔진의 복잡성에 맞게 조절됩니다:
메이저버전은 프로젝트를 한 메이저 버전에서 다른 메이저 버전으로 이동하기 위한 중요한 이식 작업을 의미하는 주요 호환성 손상이 발생할 때 증가됩니다.예를 들어, Godot 2.1에서 Godot 3.0으로 Godot 프로젝트를 포팅하려면 변환 툴을 통해 프로젝트를 실행하고 툴이 자동으로 할 수 없는 것에 대해 수동으로 많은 추가 조절을 수행해야 했습니다.
마이너버전은 호환성을 크게 손상시키지 않는 기능 릴리스에 대해 증가합니다. 매우 특정한 영역에서 사소한 호환성 손상이 마이너 버전에서 발생할 수 있지만 대부분의 프로젝트는 영향을 받거나 상당한 이식 작업이 필요하지 않습니다.그 이유는 게임 엔진으로서 Godot는 렌더링, 물리, 스크립팅 등과 같은 많은 영역을 다루며, 버그를 수정하거나 주어진 영역에서 새로운 기능을 구현하는 것은 엔진 API의 나머지 부분이 이전 버전과 호환되는 경우에도 때때로 기능의 동작을 변경하거나 클래스의 인터페이스를 수정해야 할 수도 있기 때문입니다.
팁
따라서 새 마이너 버전으로 업그레이드하는 것이 모든 사용자에게 권장되지만 프로젝트가 새 마이너 버전에서 예상대로 작동하는지 확인하려면 몇 가지 테스트가 필요합니다.
패치버전은 버그 및 보안 문제 수정, 플랫폼 지원에 대한 새로운 요구 사항 구현, 안전한 사용성 향상 백포팅에 중점을 둔 유지 관리 릴리스를 위해 증가됩니다. 패치 릴리스는 이전 버전과 호환됩니다.패치 버전에는 기존 API에 영향을 주지 않는 사소한 새 기능이 포함될 수 있으므로 기존 프로젝트에 영향을 미칠 위험이 없습니다.
팁
따라서 새 패치 버전으로 업데이트하는 것은 안전한 것으로 간주되며 안정적인 분기의 모든 사용자에게 강력히 권장됩니다.
우리는 메이저.마이너 조합을 안정적인 브랜치라고 부릅니다. 각 안정적인 브랜치는 메이저.마이너 릴리스(patch의 경우 0 제외)로 시작하고 같은 이름의 Git 브랜치의 유지 보수 릴리스를 위해 더욱 개발됩니다(예: 3.3 안정적 브랜치에 대한 패치 업데이트는 3.3 Git 브랜치에서 개발됩니다).
릴리스 지원 타임라인
안정 브랜치는 다음 안정 브랜치가 릴리스되고 첫 번째 패치 업데이트를 받을 때까지 최소한으로 지원됩니다. 실제로, 유지 관리 업데이트가 필요한 활성 사용자가 있는 한 최선의 노력으로 안정적인 분기를 지원합니다.
새 메이저 버전이 출시될 때마다 이전의 안정적인 브랜치를 장기 지원 릴리스로 만들고 복잡한 프로젝트를 새 메이저 버전으로 이식할 수 없는 해당 브랜치 사용자가 겪는 문제에 대한 수정 사항을 제공하기 위해 최선을 다합니다. 이것은 2.1 브랜치의 경우이며 Godot 4.0이 출시될 때 최신 3.x 안정 브랜치의 경우가 그렇게 될 것입니다.
주어진 마이너 릴리스 시리즈에서는 최신 패치 릴리스만 지원을 받습니다. 이전 패치 릴리스를 사용하여 문제가 발생하면 해당 시리즈의 최신 패치 릴리스로 업그레이드하고 GitHub에서 문제를 보고하기 전에 다시 테스트하세요.
버전 |
릴리스 날짜 |
지원 수준 |
Godot 4.4 (master) |
2025년 1분기 (예상) |
|
Godot 4.3 |
2020년 1월 |
|
Godot 4.3 |
2014년 12월 |
|
Godot 4.3 |
2023년 3월 |
|
Godot 4.3 |
2024년 8월 |
|
Godot 4.2 |
2023년 11월 |
|
Godot 4.1 |
2023년 7월 |
|
Godot 4.0 |
2023년 3월 |
|
Godot 3.6 (LTS) |
현재로서는 예정 시간이 없습니다. |
|
Godot 3.5 |
2014년 12월 |
|
Godot 3.5 |
2022년 8월 |
|
Godot 3.4 |
2021년 11월 |
|
Godot 3.3 |
2021년 4월 |
|
Godot 3.2 |
2020년 1월 |
|
Godot 3.1 |
2019년 3월 |
|
Godot 3.0 |
2018년 1월 |
|
Godot 2.1 |
2016년 7월 |
|
Godot 2.0 |
2016년 2월 |
|
Godot 1.1 |
2015년 5월 |
|
Godot 1.0 |
2014년 12월 |
|
범례: 
지원 - 
부분 지원 - 
지원 없음(종료) - 
개발 버전
Godot의 사전 배포판은 제작에 사용되는 것을 염두한 것이 아니며 테스팅 목적으로만 제공됩니다.
더 보기
프로젝트를 Godot 3.x에서 4.x로 마이그레이션하는 방법에 대한 지침은 Godot 3에서 Godot 4로 업그레이드를 참조하세요.
어떤 이동 메서드를 사용해야 할까요?
Godot 4.x 시리즈는 향후 3.x의 업데이트를 받는 것을 중단된 이후에도 오랫동안 지원될 예정이므로 새 프로젝트에는 Godot 4.x를 사용하는 것을 권장합니다. 한 가지 주의할 점은 많은 서드 파티 문서가 아직 Godot 4.x에 맞춰 업데이트되지 않았다는 점입니다. Godot 3.x용 튜토리얼을 따라야 하는 경우, (Godot 4.x에서 이름이 변경된 특정 노드나 메서드를 사용하려고 할 때 스크립트 오류가 발생하는 경우) Godot 3에서 Godot 4로 업그레이드를 별도의 탭에 열어 어떤 메서드의 이름이 변경되었는지 확인하는 것을 권장합니다.
프로젝트에 4.x에서 누락된 기능(예: GLES2/WebGL 1.0)이 필요한 경우, 새 프로젝트에는 Godot 3.x를 사용하는 것이 좋습니다.
프로젝트를 새 엔진 버전으로 업그레이드해야 할까요?
참고
프로젝트 작업 중에 소프트웨어를 업그레이드하는 것은 본질적으로 위험이 따르므로, 업그레이드를 시도하기 전에 프로젝트에 적합한지 신중히 고려해야 합니다. 또한, 업그레이드가 잘못될 경우를 대비해 프로젝트 백업을 하거나 버전 관리를 사용하여 데이터 손실을 방지하세요.
그럼에도 불구하고, 우리는 기존 프로젝트와의 호환성을 유지하기 위해 소규모 및 특히 패치 릴리스를 최대한 신경 써서 진행하고 있습니다.
일반적으로 프로젝트를 새로운 패치 릴리스로 업그레이드하는 것을 권장합니다. 예를 들어 4.0.2에서 4.0.3으로 업그레이드하는 것입니다. 이렇게 하면 버그 수정, 보안 업데이트 및 플랫폼 지원 업데이트를 받을 수 있으며(특히 모바일 플랫폼에서는 매우 중요), 최신 패치 릴리스만 공식 커뮤니티 플랫폼에서 지원을 받기 때문에 지속적인 지원도 받을 수 있습니다.
마이너 릴리스의 경우, 업그레이드가 적절한지 여부를 상황에 따라 결정해야 합니다. 우리는 업그레이드 과정을 가능한 한 원활하게 만들기 위해 많은 노력을 기울였지만, 마이너 릴리스에는 일부 호환성 문제가 발생할 수 있으며, 회귀(regression) 위험이 더 큽니다. 마이너 릴리스에 포함된 일부 수정 사항은 버그를 수정하기 위해 클래스의 예상 동작을 변경할 수도 있습니다. 이는 특히 문서에서 *실험적*으로 표시된 클래스에서 더 많이 발생합니다.
메이저 릴리스는 많은 새로운 기능을 가져오지만, 기존 기능을 제거하고 하드웨어 요구 사항을 높일 수 있습니다. 또한 마이너 릴리스에 비해 업그레이드 작업이 훨씬 더 많이 필요합니다. 따라서 현재 프로젝트에 만족하고 있다면, 프로젝트를 시작한 메이저 릴리스를 계속 사용하는 것이 좋습니다. 예를 들어, 프로젝트를 3.5로 시작했다면 3.5.2 및 향후 3.6으로 업그레이드하는 것을 권장하지만, 프로젝트가 4.0+의 새로운 기능이 정말 필요하지 않는 한 4.0+로 업그레이드하지 않는 것이 좋습니다.
다음 버전은 언제 출시되나요?
Godot 기여자들은 마감에 쫓기며 작업하지는 않지만, 비교적 자주 마이너 릴리스를 게시하기 위해 노력하고 있으며, Godot 3.3 이후 매년 평균 2번의 3.x 마이너 릴리스를 게시하고 있습니다.
특히 4.0의 매우 긴 릴리스 주기 이후, 우리는 더 빠른 개발 워크플로우로 전환하고 있습니다. 4.1은 4.0 출시 4개월 후에 출시되었고, 4.2는 4.1 출시 4개월 후에 출시
빈번한 마이너 릴리스를 통해 새로운 기능을 더 빠르게 제공하고(가능하면 실험적으로), 사용자 피드백을 신속하게 받아 그 기능과 사용성을 개선할 수 있습니다. 이와 마찬가지로, 일반 사용자 경험도 최종 사용자에게 더 빠르게 전달되어 더욱 안정적으로 개선될 것입니다.
유지 관리(패치) 릴리스는 필요에 따라 매우 짧은 개발 주기로 릴리스되며, 현재 안정적인 브랜치 사용자에게 프로덕션 요구 사항에 대한 최신 버그 수정을 제공합니다.
다음 3.x 마이너 버전인 3.7에 대한 현재 계획된 출시일은 없습니다. 현재 안정 출시 버전인 3.6은 Godot 3.x의 마지막 안정 브랜치일 수 있습니다. Godot 3.x는 기여자(contributor)들이 계속 유지보수하는 한 최대한의 노력으로 지원됩니다.
엔진 버전 간 호환성 기준은 무엇인가요?
참고
이 섹션은 기여자가 특정 릴리스에 대해 안전한 변경사항을 결정하는 데 사용하기 위한 것입니다. 이 목록은 포괄적이지 않으며, Godot 개발 중에 가장 흔히 접하는 상황을 개략적으로 설명합니다.
다음 변경사항은 패치 릴리스에서 허용됩니다:
대부분의 프로젝트에 큰 부정적인 영향을 미치지 않는 방식으로 버그를 수정하는 것, 예를 들어 시각적 버그나 물리적 버그를 수정하는 것. Godot의 물리 엔진은 비결정적이므로, 물리 버그 수정은 호환성을 깨뜨리는 것으로 간주되지 않습니다. 버그 수정이 많은 프로젝트에 부정적인 영향을 미칠 수 있는 경우, 이를 선택적으로 만들 필요가 있습니다 (예: 프로젝트 설정이나 별도의 메서드를 사용하는 방식).
메서드에 새로운 선택적 매개변수를 추가하기.
소규모 편집기 사용성 조정.
각 후속 패치 릴리스에서 허용되는 수정 사항에 대해 우리는 더 보수적인 경향이 있습니다. 예를 들어, 4.0.1은 4.0.4보다 더 영향력 있는 수정 사항을 받을 수 있습니다.
다음 변경사항은 마이너 릴리스에서는 허용되지만, 패치 릴리스에서는 허용되지 않습니다:
새로운 기능 학습
메서드 매개변수 이름 변경. C#에서는 메서드 매개변수를 이름으로 전달할 수 있지만(GDScript에서는 불가능), 이로 인해 C#을 사용하는 일부 프로젝트가 중단될 수 있습니다.
메서드, 멤버 변수 또는 클래스를 사용 중단으로 표시. 이는 클래스 참조에 사용 중단 플래그를 추가하여 편집기에 표시되도록 합니다. 메서드가 사용 중단으로 표시되면 다음 메이저 릴리스에서 제거될 예정입니다.
디폴트 프로젝트 테마의 시각적 요소에 영향을 미치는 변경사항.
사용자 기대에 더 잘 부응하기 위해 동작이나 출력을 크게 변경하는 버그 수정. 이에 비해 패치 릴리스에서는 기존 프로젝트가 이미 버그에 의존하거나 우회 방법을 사용하고 있을 가능성이 높기 때문에 버그가 있는 동작을 유지하는 것을 선호할 수 있습니다.
시각적 변화를 초래하는 성능 최적화.
다음 변경사항은 호환성을 깨뜨리는 변경사항으로 간주되며, 새로운 메이저 릴리스에서만 수행할 수 있습니다:
메서드, 멤버 변수, 또는 클래스의 이름을 변경하거나 제거하는 것.
노드의 상속 트리를 수정하여 다른 클래스를 상속받게 하는 것.
기존 프로젝트에 영향을 미치는 방식으로 프로젝트 설정의 기본 값을 변경하는 것. 새로운 프로젝트에만 영향을 미치려면, 프로젝트 매니저가 수정된 project.godot 파일을 작성해야 합니다.
Godot 5.0의 분기 작업이 아직 이루어지지 않았기 때문에, 현재 이러한 종류의 호환성을 깨뜨리는 변경을 하는 것을 권장하지 않습니다.
참고
메서드의 시그니처를 어떤 방식으로든 수정할 때(선택적 매개변수를 추가하는 경우 포함), GDExtension 호환성 메서드를 생성해야 합니다. 이렇게 하면 기존 GDExtension이 패치 및 마이너 릴리스에서도 계속 작동하여 사용자가 이를 다시 컴파일할 필요가 없도록 보장합니다. 자세한 정보는 호환성 중단 처리를 참조하세요.