Django의 릴리스 과정

기능 릴리스

Feature releases contain new features, improvements to existing features, and other enhancements. Each version will be mostly backwards compatible with the previous release. Exceptions to this rule will be listed in the release notes.

패치 릴리스

A release containing bug fixes and/or security fixes, issued as needed.

These releases will be 100% compatible with the associated feature release, unless this is impossible for security reasons or to prevent data loss, in which case the release notes will provide detailed upgrade instructions. Generally, you should always upgrade to the latest patch release. Each patch release supersedes earlier patch releases in its series, which may contain known security vulnerabilities.

장기 지원 릴리스

Under the A.B versioning scheme, certain feature releases are designated as long-term support (LTS) releases. These releases receive security and data loss fixes for three years.

Starting with Django 2028, there are no separate LTS releases. All feature releases receive security and data loss fixes for three years: one year of mainstream support followed by two years of extended support. See the annual release cycle for more details.

See the download page for the A.B releases that have been designated for long-term support.

공식 릴리스

Since version 1.0, and ending with Django 6.2, Django’s release numbering works as follows:

• 버전은 A.B 또는 A.B.C 형식으로 표기됩니다.

• A.B is the feature release version number.

• C is the patch release version number.

• 새 기능 릴리스에 앞서 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>`를 참고하세요.

Django 6.2 is the last release using this numbering scheme and release cadence. Please see the annual release cycle for details on the new release process.

릴리스 주기

From Django 2.0, and ending with Django 6.2, version numbers use a loose form of semantic versioning such that each version following a long-term support release will bump to the next “dot zero” version. For example: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.

SemVer makes it easier to see at a glance how compatible releases are with each other. It also helps to anticipate when compatibility shims will be removed. It’s not a pure form of SemVer as each feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn’t possible or not worth the cost. Also, deprecations started in an LTS release (X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy of keeping deprecation shims for at least two feature releases. Read on to the next section for an example.

사용 중단 정책

A feature release may deprecate certain features from previous releases. If a feature is deprecated in feature release A.x, it will continue to work in all A.x versions (for all versions of x) but raise warnings. Deprecated features will be removed in the B.0 release, or B.1 for features deprecated in the last A.x feature release to ensure deprecations are done over at least 2 feature releases.

예를 들어 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: Drop deprecation shims added in X.0 and X.1.

• Y.1: Drop deprecation shims added in X.2.

• Y.2 LTS: No deprecation shims dropped (while Y.0 is no longer supported, third-party apps need to maintain compatibility back to X.2 LTS to ease LTS to LTS upgrades).

• Z.0: Drop deprecation shims added in Y.0 and Y.1.

Features deprecated in Django 6.0, 6.1, or 6.2 are removed following the same rules, with Django 2028 taking the place of 7.0 and Django 2029 taking the place of 7.1. Features deprecated in Django 2028 or later follow the annual release cycle deprecation policy.

기능을 사용 가이드를 참조하세요.

지원되는 버전

Django 개발팀은 항상 일정 범위의 릴리스를 각기 다른 수준으로 지원합니다. 각 버전의 현재 지원 상태는 다운로드 페이지의 `the supported versions section <https://www.djangoproject.com/download/#supported-versions>`_을 참고하세요.

• 현재 개발 브랜치인 ``main``에는 새로운 기능과 상당한 리팩터링이 필요한 버그 수정이 반영됩니다.

• Patches applied to the main branch must also be applied to the last feature release branch, to be released in the next patch release of that feature series, when they fix critical problems:

  • 보안 문제

  • 데이터 손실 버그

  • 충돌 버그

  • 최신 안정 릴리스의 새 기능에서 발생하는 주요 기능 버그

  • 현재 릴리스 시리즈에서 도입된 이전 Django 버전 대비 회귀

  기본 원칙은 릴리스를 애초에 불가능하게 만들었을 버그(릴리스 블로커)에 대한 수정 사항이 마지막 기능 릴리스로 백포트된다는 것입니다.

• Security fixes and data loss bugs will be applied to the current main branch and all supported feature release branches.

• 일반적으로 문서 수정은 마지막 릴리스 브랜치에 비교적 자유롭게 백포트됩니다. 이는 최신 릴리스의 문서를 최신 상태로 정확하게 유지하는 것이 매우 중요하고, 회귀가 발생할 위험도 훨씬 낮기 때문입니다.

구체적인 예로, Django 5.1과 5.2 릴리스 사이의 중간 시점을 가정해 보겠습니다. 이 시점에서는:

• Features will be added to the development main branch, to be released as Django 5.2.

• 심각한 버그 수정은 stable/5.1.x 브랜치에 적용되어 5.1.1, 5.1.2 등으로 릴리스됩니다.

• Security fixes and bug fixes for data loss issues will be applied to main and to the stable/5.1.x, stable/5.0.x, and stable/4.2.x (LTS) branches. They will trigger the release of 5.1.1, 5.0.5, 4.2.8, etc.

• 문서 수정은 main에 적용되며, 쉽게 백포트할 수 있는 경우에는 최신 안정 브랜치인 ``5.1.x``에도 적용됩니다.

릴리스 과정

Django uses a time-based release schedule. Up to Django 6.2, feature releases happen every eight months or so. From Django 2028, they happen once a year, as described in the annual release cycle.

After each feature release, the release manager will publish a timeline for the next feature release. The timeline for an upcoming feature release can be found in the corresponding roadmap page, e.g. https://www.djangoproject.com/download/6.0/roadmap.

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주가 지나도 주요 버그가 계속 발견될 경우, 향후 진행 방식을 결정하게 됩니다(추가 릴리스 후보가 발행되고 최종 릴리스 날짜가 연기될 가능성이 높습니다).

The annual release cycle

공식 릴리스

Starting with Django 2028, Django’s release numbering works as follows:

• Versions are numbered in the form YYYY or YYYY.N.

• YYYY is the feature release version number, using the four-digit year of release, for example 2028.

• N is the patch release version number, incremented with each patch release, for example 2028.1 and 2028.2.

• Before a new feature release, there are alpha, beta, and release candidate releases, for example 2028 alpha 1, 2028 beta 1, and 2028 rc 1.

In git, each Django release will have a tag indicating its version number, signed with the Django release key. Additionally, each release series has its own branch, called stable/YYYY.x, and bugfix/security releases will be issued from those branches.

Django 프로젝트가 보안 목적으로 새 릴리스를 배포하는 방식에 대한 자세한 내용은 :doc:`our security policies </internals/security>`를 참고하세요.

릴리스 주기

One feature release will be made each calendar year. Final releases are planned for approximately the second week of January and use that calendar year’s number. The exact release date is at the release manager’s discretion.

사용 중단 정책

If a feature is deprecated in feature release YYYY, it will continue to work in the following feature release, YYYY+1, while raising warnings. The feature will be removed in YYYY+2.

For example, if a feature is deprecated in Django 2028:

• Django 2028 will contain the deprecated feature and raise a RemovedInDjango2030Warning.

• Django 2029 will continue to contain the deprecated feature.

• Django 2030 will remove the feature.

Deprecation warnings are silent by default. You can turn on display of these warnings with the python -Wd option.

기능을 사용 가이드를 참조하세요.

지원되는 버전

Each feature release series goes through two support phases:

• Mainstream support lasts one year, until the next feature release. During this time, patches applied to main are also applied to the release branch when they fix critical problems: security issues, data loss bugs, crashing bugs, major functionality bugs in new features, and regressions introduced in the current release series.

• Extended support lasts another two years. During this time, only security fixes and data loss fixes are applied.

See the supported versions section of the download page for the current state of support for each version.

As a concrete example, consider a moment in time halfway between the release of Django 2029 and 2030. At this point in time:

• Features will be added to the development main branch, to be released as Django 2030 around mid-January 2030.

• Critical bug fixes will be applied to the stable/2029.x branch, and released roughly once a month as patch releases 2029.1, 2029.2, etc.

• Security fixes and bug fixes for data loss issues will be applied to main and to each stable branch still in support, in this case, the stable/2029.x, stable/2028.x, and stable/6.2.x (LTS) branches. They will trigger a patch release for each version e.g. 2029.1, 2028.5, and 6.2.8.

• Documentation fixes will be applied to main, and, if easily backported, to the latest stable branch, stable/2029.x.

릴리스 과정

Django uses a time-based release schedule, with feature releases every year in January.

After each feature release, the release manager will publish a timeline for the next feature release. The timeline for an upcoming feature release can be found in the corresponding roadmap page, e.g. https://www.djangoproject.com/download/2028/roadmap.

Active development / Pre-feature freeze

Work begins on the feature release YYYY after the feature freeze of the previous release, i.e. when the stable/YYYY-1.x branch is forked. For Django 2028, the previous release is Django 6.2, so that branch is stable/6.2.x.

Trac의 `Django release process <https://code.djangoproject.com/#Djangoreleaseprocess>`_에서 현재 개발이 진행 중인 브랜치를 확인할 수 있습니다.

Feature freeze / Alpha release

사용 중단 및 하위 호환성이 없는 변경 사항을 포함한 모든 주요 및 부가 기능은 기능 동결 전까지 병합되어야 합니다. 이 시점까지 완료되지 않은 기능은 다음 기능 릴리스로 미뤄집니다.

At this point, the stable/YYYY.x branch will be forked from main.

Non-release blocking bug fix freeze / Beta release

After the alpha, all bug fixes merged in main are also backported to stable/YYYY.x. Refactors are backported at the discretion of the merger. Mergers will be more and more conservative with backports, to avoid introducing regressions.

In parallel to this phase, main can continue to receive new features, to be released in the YYYY+1 cycle.

Translation string freeze / Release candidate release

계획된 릴리스 후보 날짜에 릴리스 블로커가 지속적으로 보고되는 경우, 추가 테스트를 장려하기 위해 베타 2가 릴리스되며 릴리스 후보 날짜는 약 한 달 연기됩니다.

릴리스 후보는 문자열 동결 시점을 의미하며, 최종 릴리스 최소 2주 전에 진행됩니다. 이때부터 번역자들은 최종 릴리스에 반영될 번역을 제출할 수 있습니다. 이 시점 이후에는 새로운 번역 대상 문자열을 추가할 수 없습니다.

릴리스 후보 이후에는 릴리스 블로커와 문서 수정만 백포트됩니다.

Final release

Ideally, the final release will ship in approximately the second week of January.

릴리스 후보 이후 2주가 지나도 주요 버그가 계속 발견될 경우, 향후 진행 방식을 결정하게 됩니다(추가 릴리스 후보가 발행되고 최종 릴리스 날짜가 연기될 가능성이 높습니다).