Django의 릴리스 과정¶
공식 릴리스¶
버전 1.0부터 Django의 릴리스 번호 체계는 다음과 같습니다.
버전은
A.B또는A.B.C형식으로 표기됩니다.``A.B``는 기능 릴리스 버전 번호입니다. 각 버전은 이전 릴리스와 대부분 하위 호환됩니다. 이 규칙의 예외는 릴리스 노트에 나열됩니다.
``C``는 패치 릴리스 버전 번호로, 버그 수정 및 보안 릴리스에 따라 증가합니다. 이러한 릴리스는 이전 패치 릴리스와 100% 하위 호환됩니다. 단, 보안 문제나 데이터 손실 문제를 하위 호환성을 깨지 않고는 해결할 수 없는 경우에는 예외가 있습니다. 이러한 경우 릴리스 노트에서 자세한 업그레이드 지침을 제공합니다.
새 기능 릴리스에 앞서 alpha, beta, release candidate 릴리스를 만듭니다. 이는
A.B alpha/beta/rc N형식이며,A.B버전의 ``N``번째 alpha/beta/release candidate 릴리스를 의미합니다.
Git에서 각 Django 릴리스에는 버전 번호를 나타내는 태그가 있으며, 해당 태그는 Django 릴리스 키로 서명됩니다. 또한 각 릴리스 시리즈마다 ``stable/A.B.x``라는 브랜치가 있으며, 버그 수정 및 보안 릴리스는 이러한 브랜치에서 이루어집니다.
Django 프로젝트가 보안 목적으로 새 릴리스를 배포하는 방식에 대한 자세한 내용은 :doc:`our security policies </internals/security>`를 참고하세요.
- 기능 릴리스¶
기능 릴리스(A.B, A.B+1 등)는 대략 8개월마다 이루어집니다. 자세한 내용은 `release process`_를 참고하세요. 이러한 릴리스에는 새로운 기능, 기존 기능의 개선 등이 포함됩니다.
- 패치 릴리스¶
패치 릴리스(A.B.C, A.B.C+1 등)는 버그 수정 및 보안 문제 해결을 위해 필요에 따라 배포됩니다.
이러한 릴리스는 보안상의 이유나 데이터 손실을 방지하기 위해 불가피한 경우를 제외하고, 해당 기능 릴리스와 100% 호환됩니다. 따라서 “최신 패치 릴리스로 업그레이드해야 할까요?”라는 질문에 대한 답은 항상 “예”입니다.
- 장기 지원 릴리스¶
특정 기능 릴리스는 장기 지원(LTS) 릴리스로 지정됩니다. 이러한 릴리스에는 보안 및 데이터 손실 관련 수정이 일정 기간 동안 적용되며, 일반적으로 그 기간은 3년입니다.
장기 지원으로 지정된 릴리스는 `the download page`_를 참고하세요.
릴리스 주기¶
Django 2.0부터 버전 번호는 느슨한 형태의 `semantic versioning <https://semver.org/>`_을 따르며, LTS 이후의 각 버전은 다음 “.0” 버전으로 증가합니다. 예: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS) 등.
SemVer를 사용하면 릴리스 간 호환성을 한눈에 파악하기 쉽습니다. 또한 호환성 shim이 언제 제거될지 예측하는 데에도 도움이 됩니다. 다만 지원 중단 경로를 마련할 수 없거나 그 비용이 적절하지 않은 경우에는 각 기능 릴리스에 일부 하위 호환성이 깨지는 변경 사항이 문서화되어 포함되므로, 순수한 형태의 SemVer는 아닙니다. 또한 LTS 릴리스(X.2)에서 시작된 지원 중단은, 지원 중단 shim을 최소 두 개의 기능 릴리스 동안 유지하는 정책에 따라 “.0”이 아닌 릴리스(Y.1)에서 제거됩니다. 예시는 다음 섹션을 참고하세요.
사용 중단 정책¶
기능 릴리스에서는 이전 릴리스의 특정 기능이 사용 중단될 수 있습니다. 기능 릴리스 A.x에서 기능이 사용 중단되면, 해당 기능은 모든 A.x 버전(모든 x)에 걸쳐 계속 동작하지만 경고가 표시됩니다. 사용 중단된 기능은 B.0 릴리스에서 제거되거나, 마지막 A.x 기능 릴리스에서 사용 중단된 기능의 경우 최소 두 번의 기능 릴리스 동안 사용 중단 상태가 유지되도록 B.1에서 제거됩니다.
예를 들어 Django 4.2에서 특정 함수의 사용 중단을 시작하기로 했다면:
Django 4.2에는 해당 함수의 하위 호환 구현이 포함되며, 이 구현은
RemovedInDjango51Warning경고를 발생시킵니다.Django 5.0(4.2의 다음 버전)에도 해당 함수의 하위 호환 구현이 계속 포함됩니다.
Django 5.1에서는 해당 기능이 완전히 제거됩니다.
기본적으로 경고는 표시되지 않습니다. python -Wd 옵션을 사용하면 해당 경고를 표시할 수 있습니다.
보다 일반적인 예시:
X.0
X.1
X.2 LTS
Y.0: X.0 및 X.1에서 추가된 사용 중단 shim을 제거합니다.
Y.1: X.2에서 추가된 사용 중단 shim을 제거합니다.
Y.2 LTS: 사용 중단 shim을 제거하지 않습니다(Y.0은 더 이상 지원되지 않지만, 서드파티 앱이 LTS 간 업그레이드를 원활하게 수행할 수 있도록 X.2 LTS까지의 호환성을 유지해야 합니다).
Z.0: Y.0 및 Y.1에서 추가된 사용 중단 shim을 제거합니다.
기능을 사용 가이드를 참조하세요.
지원되는 버전¶
Django 개발팀은 항상 일정 범위의 릴리스를 각기 다른 수준으로 지원합니다. 각 버전의 현재 지원 상태는 다운로드 페이지의 `the supported versions section <https://www.djangoproject.com/download/#supported-versions>`_을 참고하세요.
현재 개발 브랜치인 ``main``에는 새로운 기능과 상당한 리팩터링이 필요한 버그 수정이 반영됩니다.
패치는 main 브랜치뿐만 아니라 마지막 기능 릴리스 브랜치에도 적용되어야 하며, 해당 기능 시리즈의 다음 패치 릴리스에 포함됩니다. 이는 다음과 같은 심각한 문제를 수정하는 경우에 해당합니다.
보안 문제
데이터 손실 버그
충돌 버그
최신 안정 릴리스의 새 기능에서 발생하는 주요 기능 버그
현재 릴리스 시리즈에서 도입된 이전 Django 버전 대비 회귀
기본 원칙은 릴리스를 애초에 불가능하게 만들었을 버그(릴리스 블로커)에 대한 수정 사항이 마지막 기능 릴리스로 백포트된다는 것입니다.
보안 수정 및 데이터 손실 버그 수정은 현재 main 브랜치와 마지막 두 개의 기능 릴리스 브랜치, 지원 중인 기타 모든 장기 지원 릴리스 브랜치에 적용됩니다.
일반적으로 문서 수정은 마지막 릴리스 브랜치에 비교적 자유롭게 백포트됩니다. 이는 최신 릴리스의 문서를 최신 상태로 정확하게 유지하는 것이 매우 중요하고, 회귀가 발생할 위험도 훨씬 낮기 때문입니다.
구체적인 예로, Django 5.1과 5.2 릴리스 사이의 중간 시점을 가정해 보겠습니다. 이 시점에서는:
기능은 Django 5.2로 릴리스될 예정인 main 개발 브랜치에 추가됩니다.
심각한 버그 수정은
stable/5.1.x브랜치에 적용되어 5.1.1, 5.1.2 등으로 릴리스됩니다.보안 수정 및 데이터 손실 버그 수정은
main``과 ``stable/5.1.x,stable/5.0.x,stable/4.2.x``(LTS) 브랜치에 적용됩니다. 이러한 수정은 ``5.1.1,5.0.5,4.2.8등의 릴리스로 이어집니다.문서 수정은 main에 적용되며, 쉽게 백포트할 수 있는 경우에는 최신 안정 브랜치인 ``5.1.x``에도 적용됩니다.
릴리스 과정¶
Django는 시간 기반 릴리스 일정을 따르며, 기능 릴리스는 약 8개월 간격으로 이루어집니다.
각 기능 릴리스 이후 릴리스 매니저는 다음 기능 릴리스의 일정을 공개합니다. 다음 기능 릴리스의 일정은 해당 위키 로드맵 페이지(예: https://code.djangoproject.com/wiki/Version6.0Roadmap)에서 확인할 수 있습니다.
기능 릴리스 일정 및 단계¶
Active development / Pre-feature freeze¶
기능 릴리스 A.B 작업은 이전 릴리스의 기능 동결 이후, 즉 stable/A.B-1.x 브랜치가 분기된 시점부터 시작됩니다.
Trac의 `Django release process <https://code.djangoproject.com/#Djangoreleaseprocess>`_에서 현재 개발이 진행 중인 브랜치를 확인할 수 있습니다.
Feature freeze / Alpha release¶
사용 중단 및 하위 호환성이 없는 변경 사항을 포함한 모든 주요 및 부가 기능은 기능 동결 전까지 병합되어야 합니다. 이 시점까지 완료되지 않은 기능은 다음 기능 릴리스로 미뤄집니다.
이 시점에서 stable/A.B.x 브랜치는 ``main``에서 분기됩니다.
Non-release blocking bug fix freeze / Beta release¶
alpha 릴리스 이후에는 ``main``에 병합된 모든 버그 수정이 ``stable/A.B.x``에도 백포트됩니다. 리팩터링의 백포트 여부는 Merger의 판단에 따릅니다. Merger는 회귀를 방지하기 위해 점차 보수적으로 백포트를 진행합니다.
이 단계와 병행하여 main``은 ``A.B+1 주기에서 릴리스될 예정인 새 기능을 계속 반영할 수 있습니다.
Translation string freeze / Release candidate release¶
계획된 릴리스 후보 날짜에 릴리스 블로커가 지속적으로 보고되는 경우, 추가 테스트를 장려하기 위해 베타 2가 릴리스되며 릴리스 후보 날짜는 약 한 달 연기됩니다.
릴리스 후보는 문자열 동결 시점을 의미하며, 최종 릴리스 최소 2주 전에 진행됩니다. 이때부터 번역자들은 최종 릴리스에 반영될 번역을 제출할 수 있습니다. 이 시점 이후에는 새로운 번역 대상 문자열을 추가할 수 없습니다.
릴리스 후보 이후에는 릴리스 블로커와 문서 수정만 백포트됩니다.
Final release¶
이상적으로는 마지막 릴리스 후보 이후 2주 뒤에 최종 릴리스가 배포됩니다.
릴리스 후보 이후 2주가 지나도 주요 버그가 계속 발견될 경우, 향후 진행 방식을 결정하게 됩니다(추가 릴리스 후보가 발행되고 최종 릴리스 날짜가 연기될 가능성이 높습니다).
Bug-fix releases¶
기능 릴리스(예: A.B) 이후에는 이전 릴리스가 버그 수정 모드로 전환됩니다.
이전 기능 릴리스 브랜치(예: stable/A.B-1.x) 에는 버그 수정이 포함됩니다. main에서 수정된 심각한 버그는 버그 수정 브랜치에*도* 반드시 반영되어야 합니다. 따라서 커밋은 버그 수정과 기능 추가를 명확히 구분해야 합니다. main에 커밋한 개발자는 현재 버그 수정 브랜치에도 해당 수정 사항을 적용할 책임이 있습니다.
