Django 릴리스하는 방법

이 문서는 Django 릴리스 방법을 설명합니다.

변경 사항을 적용할 때는 이 지침을 최신 상태로 유지하세요! 이 문서의 목적은 규정하기보다는 설명하는 데 있으므로, 필요에 따라 자유롭게 간소화하거나 변경해도 됩니다. 다만, 변경 사항이 있다면 이 문서에도 반드시 반영하세요!

개요

필요할 수 있는 릴리스 유형은 세 가지입니다.

• 보안 릴리스: 취약점을 공개하고 수정합니다. 일반적으로 두세 개의 릴리스를 동시에 진행하게 됩니다. 예를 들어 3.2.x, 4.0.x, 그리고 시점에 따라 4.1.x가 포함될 수 있습니다.

• 일반 버전 릴리스: 최종 릴리스(예: 4.1) 또는 버그 수정 업데이트(예: 4.1.1)

• 사전 릴리스: 예를 들어 4.2 alpha, beta, 또는 rc

전체 과정을 간단히 정리하면 다음과 같습니다.

1. 보안 릴리스인 경우, 실제 릴리스 일주일 전에 보안 배포 목록에 미리 알립니다.

2. 릴리스 노트를 검토하면서 구성과 문서상의 오류를 점검합니다. 블로그 게시물과 이메일 공지 초안을 작성합니다.

3. 버전 번호를 업데이트하고 릴리스 산출물을 생성합니다.

4. ``djangoproject.com``의 관리자에서 새 ``Release``를 생성합니다.

   1. 올바른 날짜를 설정하되 is_active 플래그는 비활성화해야 합니다.

   2. 릴리스 산출물(tarball, wheel, checksums)을 업로드합니다.

5. 패키지 서명을 검증하고, 설치할 수 있는지 확인하며, 최소한의 기능이 정상적으로 동작하는지 확인합니다.

6. PyPI에 새 버전을 업로드합니다.

7. djangoproject.com 관리자에서 각 릴리스의 is_active 플래그를 활성화합니다.

8. 블로그 글을 게시하고 이메일 공지를 보냅니다.

9. 릴리스 이후, 안정 브랜치에서 버전 번호를 업데이트합니다.

10. 다음 패치 릴리스용 기본 릴리스 노트를 main 브랜치에 추가한 뒤 백포트합니다.

세부 사항이 많으니 계속 읽어보세요.

Use the checklists app

To generate a checklist compiling the tasks described below as relevant to the specific release(s) you are issuing, use the checklists app in the project admin. This populates a lot of boilerplate you will need for announcements, CVE publication, and hashes for commit messages. By using this app for preparing security issue metadata, your peer releasers can check your entries and consult them again in the future. (Example)

사전 요구 사항

시작하기 전에 몇 가지 준비가 필요합니다. 이번이 첫 번째 릴리스라면, 다른 릴리서와 협력하여 필요한 사항을 모두 준비하고 필요한 접근 권한을 요청하기 위해 Ops 메일링 리스트에 메일을 보내야 합니다.

• 다음 도구가 설치된 Unix 환경이 필요합니다(알파벳 순).

  • bash

  • git

  • GPG

  • make

  • man

  • 해싱 도구(일반적으로 Linux에서는 md5sum, sha1sum, sha256sum, macOS에서는 md5, shasum)

  • python

• GPG 키 쌍. 이 키의 개인 키는 안전하게 보관해야 합니다. 공개 키는 GitHub 계정과 “confirm release” 작업이 실행되는 Jenkins 서버에 업로드해야 합니다.

  하나 이상의 GPG 키

  사용하려는 키가 기본 서명 키가 아니라면, 아래에 표시된 모든 GPG 서명 명령에 ``-u [e-mail]``을 추가해야 합니다. 이때 ``[e-mail]``은 사용하려는 키에 연결된 이메일 주소입니다.

• 산출물 빌드를 위한 Python 가상 환경(Python 3.9 이상)에는 다음 필수 Python 패키지가 설치되어 있어야 합니다.

  $ python -m pip install build twine
  

• 바이너리 파일을 업로드할 수 있도록 Django’s project on PyPI <https://pypi.org/project/Django/>`_에 대한 접근 권한이 필요하며, 필요할 경우 `yank a release <https://pypi.org/help/#yanked>`_를 수행할 수 있는 추가 권한을 갖추는 것이 이상적입니다. `official documentation <https://pypi.org/help/#apitoken>`_에 따라 프로젝트 범위의 토큰을 생성하고 ``$HOME/.pypirc` 파일을 다음과 같이 설정합니다.

  ~/.pypirc

  [distutils]
    index-servers =
      pypi
      django
  
  [pypi]
    username = __token__
    password = # User-scoped or project-scoped token, to set as the default.
  
  [django]
    repository = https://upload.pypi.org/legacy/
    username = __token__
    password = # A project token.
  

• Manager 역할로 Django’s project on Transifex <https://app.transifex.com/django/django/>`_에 대한 접근 권한이 필요합니다. `user setting section <https://app.transifex.com/user/settings/api/>`_에서 API 토큰을 생성하고 ``$HOME/.transifexrc` 파일을 다음과 같이 설정합니다.

  ~/.transifexrc

  [https://www.transifex.com]
    rest_hostname = https://rest.api.transifex.com
    token = # API token
  

• “Site maintainer” 권한으로 ``djangoproject.com``의 Django 관리자에 접근할 수 있어야 합니다.

• Django Forum - Announcements category <https://forum.djangoproject.com/c/announcements/7>`_에 게시글을 작성하고 `django-announce 메일링 리스트로 이메일을 보낼 수 있는 권한이 필요합니다.

• GitHub의 django-security 저장소에 접근할 수 있어야 합니다. 이를 통해 무엇보다도 사전 공지 메일링 리스트(보안 릴리스 준비 작업에 필요함)에 접근할 수 있습니다.

• `Read the Docs <https://readthedocs.org/projects/django/>`_의 Django 프로젝트에 대한 접근 권한이 필요합니다.

사전 릴리스 작업

릴리스 과정을 시작하기 전에 몇 가지 항목을 미리 처리해야 합니다. 이러한 작업은 릴리스 약 일주일 전부터 시작되며, 대부분은 실제 릴리스 전까지 언제든지 완료할 수 있습니다.

보안 릴리스 10일 전(또는 그 이상)

1. Reserve one CVE ID per security issue as follows. (Or, if you lack CNA credentials, email [e-mail] with a request.)

   • Enable virtual environment with cvelib installed.

   • Export user information:

     $ export CVE_USER=<user-email>@djangoproject.com CVE_ORG=DSF
     

   • Reserve:

     $ cve --interactive reserve <quantity>
     

2. git format-patch``를 사용하여 관련 비공개 패치를 생성합니다. ``main 브랜치용 패치 하나와 각 안정 브랜치용 패치 하나씩 생성합니다.

보안 릴리스 일주일 전

1. Send out pre-notification exactly one week before the security release. The template for that email and a list of the recipients are in the private django-security GitHub wiki. BCC the pre-notification recipients, and be sure to include the relevant CVE IDs. Attach all the relevant patches (targeting main and the stable branches), and sign the email text with the key you’ll use for the release, with a command like:

   $ gpg --clearsign --digest-algo SHA256 prenotification-email.txt
   

2. 다음과 같은 일반적인 메시지로 예정된 보안 릴리스를 django-announce에 공지하세요.

   Notice of upcoming Django security releases (3.2.24, 4.2.10 and 5.0.2)
   
   Django versions 5.0.2, 4.2.10, and 3.2.24 will be released on Tuesday,
   February 6th, 2024 around 1500 UTC. They will fix one security defect
   with severity "moderate".
   
   For details of severity levels, see:
   https://docs.djangoproject.com/en/dev/internals/security/#how-django-discloses-security-issues
   

3. Prepare issue metadata: * Severity * Short description * Reporter * Remediator * Reported at * Confirmed at (usually date CVE reserved) * CWE Problem Type * CAPEC Impact Type * CVSS (4.0) Score & Vector

릴리스 며칠 전

1. 릴리스가 가까워지면 Trac을 확인하여 예정된 릴리스에 릴리스 차단 이슈가 남아 있지 않은지 점검하세요. 사전에 정해진 보안 릴리스 날짜를 맞추는 등의 예외적인 상황에서는 릴리스 차단 이슈가 남아 있더라도 릴리스를 진행할 수 있습니다. 릴리스 차단 이슈가 남은 상태에서 릴리스를 진행할지, 또는 필요한 경우 비보안 릴리스의 날짜를 연기할지는 릴리서가 판단하여 결정합니다.

2. 다른 머저들에게 이번 릴리스에 아직 커밋되지 않은 변경 사항은 없는지 확인하세요.

3. 릴리스 노트를 검토하고, 온라인 버전도 확인하여 :ref:`catch any broken links <documentation-link-check>`나 reST 오류가 없는지 확인하세요. 릴리스 노트에 올바른 날짜가 포함되어 있는지도 확인하세요.

4. 릴리스 노트에 사용 중단으로 표시된 API의 사용 중단 일정이 언급되어 있는지, 그리고 Python 버전 지원 변경 사항도 언급되어 있는지 다시 한번 확인하세요.

5. 릴리스 노트 인덱스에 새 릴리스 노트로 연결되는 링크가 있는지 다시 한번 확인하세요. 이 링크는 ``docs/releases/index.txt``에 있습니다.

6. If this is a feature release, ensure translations from Transifex have been integrated.

   Transifex 계정을 설정하는 것 외에도 `tx CLI <https://developers.transifex.com/docs/cli>`_를 ``PATH``에서 사용할 수 있어야 합니다. 그런 다음, 다음 명령을 실행하여 특정 날짜 이후의 모든 번역을 가져올 수 있습니다.

   $ python scripts/manage_translations.py fetch -v 1 --since=<some date>
   

   ``–since``에 사용할 적절한 값을 정하려면, ``Updated translations from Transifex``와 비슷한 문구의 가장 최근 커밋 날짜를 확인한 후 그보다 며칠 이전 날짜를 사용하세요.

   이 명령은 실행하는 데 다소 시간이 걸립니다. 실행이 완료되면 출력 내용을 주의 깊게 확인하여 발생할 수 있는 오류나 경고가 있는지 살펴보세요. 오류나 경고가 있다면, 각각의 사례에 맞게 디버깅하고 해결해야 합니다.

   최근에 가져온 번역은 일부 수동으로 조정해야 합니다. 먼저, PO-Revision-Date 값은 POT-Creation-Date``보다 이후 시점이 되도록 수동으로 조정해야 합니다. 다음과 유사한 명령을 사용하여 모든 ``.po 파일을 일괄 업데이트할 수 있습니다(관련 안정 브랜치와 diff를 비교하세요).

   $ git diff --name-only stable/5.0.x | grep "\.po"  | xargs sed -ri "s/PO-Revision-Date: [0-9\-]+ /PO-Revision-Date: $(date -I) /g"
   

   마지막으로 변경되거나 추가된 파일(.po``와 ``.mo)을 커밋하고 해당 릴리스의 안정 브랜치를 대상으로 하는 새 PR을 생성하세요(예: PR updating translations for 4.2).

   병합되면 변경 사항을 main 브랜치(example commit)에 반영하세요.

7. 다음과 같이 :ref:`Update the django-admin manual page <django-admin-manpage>`을 참고해 django-admin 매뉴얼 페이지를 업데이트하세요.

   $ cd docs
   $ make man
   $ man _build/man/django-admin.1  # do a quick sanity check
   $ cp _build/man/django-admin.1 man/django-admin.1
   

   그런 다음 변경된 매뉴얼 페이지를 커밋합니다.

8. 새 시리즈의 “dot zero” 릴리스인 경우 django-docs-translations 저장소의 현재 안정 브랜치에서 새 브랜치를 생성하세요. 예를 들어 Django 4.2를 릴리스할 때는 다음과 같습니다.

   $ git checkout -b stable/4.2.x origin/stable/4.1.x
   $ git push origin stable/4.2.x:stable/4.2.x
   

9. 릴리스를 공지하는 블로그 게시물을 작성하세요. 게시물은 언제든지 관리자에서 작성한 다음 비활성 상태로 표시할 수 있습니다. 다음은 몇 가지 예시입니다: `example security release announcement`__, `example regular release announcement`__, `example pre-release announcement`__.

기능 동결 며칠 전

alpha 릴리스를 준비하기 위해 djangoproject 서버에 /home/www/www/media/releases/A.B 디렉토리를 생성해야 합니다.

기능 동결에 앞서, 다음 기능 릴리스를 준비하기 위해 main 브랜치를 대상으로 하는 브랜치를 생성해야 합니다. 이 브랜치는 동결 며칠 전에 검토 및 승인을 받아야 하며, 안정 브랜치가 생성된 이후 병합될 수 있도록 해야 합니다. 이 브랜치에서는 다음 항목을 처리해야 합니다.

1. django/__init__.py``의 ``VERSION 튜플을 다음 예정된 릴리스 버전으로 올리도록 업데이트하세요(example commit).

2. 다음 기능 릴리스의 스텁 릴리스 노트를 작성하세요. 이전 기능 릴리스의 스텁을 사용하거나, 현재 버전의 내용을 복사한 다음 제목만 남기고 나머지 대부분을 삭제하면 됩니다(example commit).

3. 두 번의 릴리스 전 문서에 있는 .. versionadded:: 및 .. versionchanged:: 지시문과 그보다 더 오래된 지시문도 제거하세요. 예를 들어 Django 5.1에서는 4.2에 대한 노트가 삭제됩니다(example commit).

4. 사용 중단 주기가 끝난 기능은 해당 문서와 .. deprecated:: 지시문을 포함해 제거하세요. 각 제거 작업은 명확성을 위해 별도의 커밋으로 수행하세요. 커밋 메시지에는 가능하다면 사용 중단이 시작된 원본 티켓을 참조할 수 있도록 Refs #XXXXX -- 접두사를 추가하세요. 이 변경 사항이 릴리스 노트의 제거된 기능 섹션에 기록되도록 하세요(example commit).

5. ``django.contrib.auth.hashers.PBKDF2PasswordHasher``의 기본 PBKDF2 반복 횟수를 약 20% 증가시키세요(적절히 반올림한 값으로). 테스트를 실행하고, 실패하는 해셔 테스트 3개를 새로운 값에 맞게 업데이트하세요. 이 변경 사항이 릴리스 노트에 기록되도록 하세요(example commit).

과거 기능 릴리스의 bootstrap 브랜치에 대한 구체적인 예시: 5.2 bootstrap, 5.1 bootstrap, 5.0 bootstrap

기능 동결 작업

1. 릴리스 노트의 빈 섹션을 제거하세요(example commit).

2. 로컬에서 릴리스 노트를 빌드한 후 읽어 보세요. 필요한 경우 흐름을 개선하거나 문법을 수정하세요(example commit).

3. ``main``에서 새 안정 브랜치를 생성하세요. ``upstream``을 최신 상태로 가져와 업데이트하세요. 예를 들어 Django 5.2를 기능 동결할 때:

   $ git fetch upstream
   $ git checkout -b stable/5.2.x upstream/main
   $ git push upstream -u stable/5.2.x:stable/5.2.x
   

   동시에 안정 릴리스 브랜치의 docs/conf.py``에서 ``django_next_version 변수가 새로운 개발 버전을 가리키도록 설정하세요. 예를 들어 ``stable/5.2.x``를 생성할 때, 새 안정 브랜치에서 ``django_next_version``을 ``’6.0’``으로 설정합니다(example commit).

4. djangoproject.com``의 `admin`__에 다음 버전을 위한 ``Release 항목을 생성하세요. 각 마일스톤(alpha, beta, rc, final)마다 추가하고, *is active*는 unreleased로 표시되도록 비워 두세요. 합의된 일정에 따라 목표 날짜를 설정하고, 해당되는 경우 LTS 플래그도 설정하세요. X.Y 로드맵 페이지는 ``/download/X.Y/roadmap/``에서 확인할 수 있습니다.

   예를 들어 stable/5.2.x``를 생성할 때는 ``6.0a1, 6.0b1, 6.0rc1, 6.0 각각에 Release 항목을 추가하세요. 그러면 6.0 로드맵은 https://www.djangoproject.com/download/6.0/roadmap/에서 확인할 수 있습니다.

5. Add document release page in the admin`__로 이동하여 새롭게 생성된 ``Release` 객체에 대한 영어용 DocumentRelease 객체를 생성하세요. 기본값으로 설정하지 마세요.

6. Read the Docs <https://readthedocs.org/projects/django/>`_에 새 브랜치를 추가하세요. 자동으로 생성되는 버전 이름(“stable-A.B.x”)은 Read the Docs에서 사용하는 버전 이름(“A.B.x”)과 다르므로, Read the Docs 설정에서 해당 버전이 ``A.B.x` 슬러그를 가리키도록 업데이트하고 활성화하세요. See more details.

7. PyPI에 새로운 Trove classifier를 제안하는 PR을 생성하세요. 예를 들어 Framework :: Django :: 5.2.

8. 현재 개발이 진행 중인 브랜치를 업데이트하고 Trac의 `Django release process <https://code.djangoproject.com/#Djangoreleaseprocess>`_에 사전 릴리스 브랜치를 추가하세요.

9. djangoproject.com의 docs/fixtures/doc_releases.json JSON fixture를 업데이트하여, 프로덕션 DB에 접근할 수 없는 사용자도 최신 상태의 문서 사이트를 실행할 수 있도록 하세요(example PR). 이는 최종 릴리스 이후에 병합됩니다.

실제 릴리스 진행

이제 재미있는 부분입니다. 실제로 릴리스를 배포하는 단계입니다! **여러 릴리스**를 진행하는 경우, 릴리스마다 이 단계를 반복하세요.

1. 릴리스를 진행하려는 버전에 대해 `Jenkins`__ 상태가 정상(녹색)인지 확인하세요. Jenkins 상태가 정상이 될 때까지는 릴리스를 진행하지 않는 것이 좋으며, 최신 정상 빌드에 릴리스하려는 변경 사항이 포함되어 있는지도 확인하세요.

2. 이번 릴리스의 릴리스 노트를 정리하세요. 이 변경 사항은 ``main``에 적용한 후, 해당 버전의 릴리스 노트가 있는 모든 브랜치에 백포트하세요.

   1. 기능 릴리스의 경우, 릴리스 노트 상단의 UNDER DEVELOPMENT 헤더를 제거하고 Expected 접두사를 제거한 다음 필요한 경우 릴리스 날짜를 업데이트하세요(example commit).

   2. 패치 릴리스의 경우, 모든 릴리스에서 Expected 접두사를 제거하고 필요한 경우 릴리스 날짜를 업데이트하세요(example commit).

3. 릴리스는 항상 릴리스 브랜치에서 시작하므로, 최신 상태의 안정 브랜치에 있는지 확인하세요. 또한 릴리스할 각 버전에 대해 깨끗한 전용 가상 환경을 준비해 두어야 합니다. 예를 들어:

   $ git checkout stable/4.1.x
   $ git pull
   

4. 보안 릴리스인 경우, django-security``에서 적절한 패치를 병합하세요. 각 패치가 머지 커밋이 아닌 릴리스 브랜치의 일반 커밋이 되도록 필요에 따라 리베이스하세요. ``--ff-only 플래그를 사용하여 병합하세요. 예를 들어:

   $ git checkout stable/4.1.x
   $ git merge --ff-only security/4.1.x
   

   (security/4.1.x``가 ``django-security 저장소에서 4.1 시리즈의 다음 릴리스에 필요한 보안 패치를 포함하는 브랜치라고 가정합니다.)

   git이 --ff-only``로 병합을 거부하면 보안 패치 브랜치로 전환한 뒤 병합하려는 브랜치를 기준으로 리베이스한 다음(``git checkout security/4.1.x; git rebase stable/4.1.x), 다시 돌아와 병합하세요. 각 보안 수정의 커밋 메시지에는 해당 커밋이 보안 수정임을 명시하고 이후 공지가 있을 것임을 안내하세요(example security commit).

5. 릴리스 시 ``django/__init__.py``의 버전 번호를 업데이트하세요. ``VERSION``에 대한 자세한 내용은 아래 notes on setting the VERSION tuple`_참조하세요(:commit:`example commit <2719a7f8c161233f45d34b624a9df9392c86cc1b>).

   1. 사전 릴리스 패키지인 경우, pyproject.toml``의 "Development Status" trove 분류자도 이에 맞게 수정하세요. ``rc 사전 릴리스에서는 trove 분류자를 변경하지 않아야 합니다(example commit for alpha release, example commit for beta release).

   2. 그 외의 경우, 분류자가 ``Development Status :: 5 - Production/Stable``로 설정되어 있는지 확인하세요.

아티팩트 빌드하기

필요에 따라 헬퍼 스크립트 사용하기

scripts 폴더의 헬퍼 스크립트를 사용하면 아래 단계를 일부 간소화할 수 있습니다.

• 릴리스 스크립트 실행 예시:

$ PGP_KEY_ID=<key-id> PGP_KEY_URL=<key-url> DEST_FOLDER=~/releases scripts/do_django_release.py

• 릴리스 검증(아티팩트 업로드 후)

$ VERSION=5.2.1 scripts/verify_release.sh

1. ``git tag``를 사용해 릴리스를 태그하세요. 예를 들어:

   $ git tag --sign --message="Tag 4.1.1" 4.1.1
   

   ``git tag –verify <tag>``를 실행해 작업 결과를 확인할 수 있습니다.

2. ``git clean -dfx``를 실행하여 작업 트리가 완전히 깨끗한 상태인지 확인하세요.

3. python -m build``를 실행해 릴리스 패키지를 생성하세요. 이 명령을 실행하면 ``dist/ 디렉터리에 릴리스 아티팩트(tarball 및 wheel)가 생성됩니다. Django 5.0 이하에서는 ``make -f extras/Makefile``을 실행해야 합니다.

4. 릴리스 패키지 해시를 생성하세요:

   $ cd dist
   $ md5sum *
   $ sha1sum *
   $ sha256sum *
   

5. 해시와 릴리스 정보를 담은 체크섬 파일 Django-<<VERSION>>.checksum.txt``를 생성하세요. 아래 템플릿을 사용해 올바른 버전, 날짜, GPG 키 ID(``gpg --list-keys --keyid-format LONG), 릴리스 매니저의 GitHub 사용자명, 릴리스 URL, 체크섬을 입력하세요:

   This file contains MD5, SHA1, and SHA256 checksums for the source-code
   tarball and wheel files of Django <<VERSION>>, released <<DATE>>.
   
   To use this file, you will need a working install of PGP or other
   compatible public-key encryption software. You will also need to have
   the Django release manager's public key in your keyring. This key has
   the ID ``XXXXXXXXXXXXXXXX`` and can be imported from the MIT
   keyserver, for example, if using the open-source GNU Privacy Guard
   implementation of PGP:
   
       gpg --keyserver pgp.mit.edu --recv-key XXXXXXXXXXXXXXXX
   
   or via the GitHub API:
   
       curl https://github.com/<<RELEASE MANAGER GITHUB USERNAME>>.gpg | gpg --import -
   
   Once the key is imported, verify this file:
   
       gpg --verify <<THIS FILENAME>>
   
   Once you have verified this file, you can use normal MD5, SHA1, or SHA256
   checksumming applications to generate the checksums of the Django
   package and compare them to the checksums listed below.
   
   Release packages
   ================
   
   https://www.djangoproject.com/download/<<VERSION>>/tarball/
   https://www.djangoproject.com/download/<<VERSION>>/wheel/
   
   MD5 checksums
   =============
   
   <<MD5SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<MD5SUM>>  <<RELEASE WHL FILENAME>>
   
   SHA1 checksums
   ==============
   
   <<SHA1SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<SHA1SUM>>  <<RELEASE WHL FILENAME>>
   
   SHA256 checksums
   ================
   
   <<SHA256SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<SHA256SUM>>  <<RELEASE WHL FILENAME>>
   

6. 체크섬 파일에 서명하세요(gpg --clearsign --digest-algo SHA256 Django-<version>.checksum.txt). 이 명령을 실행하면 서명된 문서 ``Django-<version>.checksum.txt.asc``가 생성되며, ``gpg –verify Django-<version>.checksum.txt.asc``로 이를 검증할 수 있습니다.

릴리스 공개하기

이제 릴리스를 공개할 준비가 되었습니다. 아래 단계를 따르세요.

1. djangoproject.com 관리자 페이지 <https://www.djangoproject.com/admin/releases/release/add/>`_에서 새 ``Release` 항목을 생성하세요. 보안 릴리스인 경우, 공지된 릴리스 시각 15분 전에 진행하고 그보다 일찍 진행하지 마세요:

   버전

   tarball(django-<version>.tar.gz)에 정의된 버전 번호와 일치해야 합니다. 예: “5.2”, “4.1.1”, “4.2rc1”

   Is active

   릴리스가 완전히 공개될 때까지는(마지막 단계) False로 설정하세요.

   LTS

   릴리스가 LTS 브랜치에 속하는 경우 활성화하세요.

   날짜

   릴리스 날짜를 오늘로 설정하세요. ``is_active``가 활성화되기 전까지 이 릴리스는 공개되지 않습니다.

   아티팩트

   앞서 생성한 tarball(django-<version>.tar.gz), wheel(django-<version>-py3-none-any.whl), 체크섬(django-<version>.checksum.txt.asc) 파일을 업로드하세요.

2. ``pip``를 사용해 릴리스 패키지가 올바르게 설치되는지 테스트하세요. 다음은 한 가지 간단한 방법입니다(바이너리 사용 가능 여부, 설치 정상 여부, 마이그레이션 및 개발 서버가 정상적으로 시작되는지 확인하고 기본적인 실수도 잡아낼 수 있습니다): https://code.djangoproject.com/wiki/ReleaseTestNewVersion

3. Jenkins에서 `confirm-release`__ 빌드를 실행해 체크섬 파일을 검증하세요(예: https://media.djangoproject.com/pgp/Django-4.2rc1.checksum.txt의 경우 4.2rc1 사용).

4. 릴리스 패키지를 PyPI에 업로드하세요:

   $ twine upload --repository django dist/*
   

5. djangoproject.com 관리자에서 새로 생성한 Release``를 업데이트하고 ``is_active 플래그를 활성화하세요.

6. 작업 내용과 새 태그를 푸시하세요:

   $ git push
   $ git push --tags
   

7. 릴리스 발표 블로그 글을 게시하세요.

8. 새 버전 릴리스(예:. 4.1, 4.2)의 경우, docs.djangoproject.com 데이터베이스의 해당 DocumentRelease 객체에서 is_default 플래그를 ``True``로 설정해 문서의 기본 안정 버전을 업데이트하세요(이렇게 하면 다른 항목은 자동으로 ``False``로 전환됩니다). 이 작업은 사이트 관리자 페이지에서 할 수 있습니다.

   이전 릴리스 항목이 있는 각 언어에 대해 새 DocumentRelease 객체를 생성하세요. 이어서 django-docs-translations repository`__의 현재 안정 브랜치에서 ``manage_translations.py robots_txt` 명령을 실행해 생성된 결과를 복사하여 djangoproject.com의 `robots.docs.txt`__ 파일을 업데이트하세요. 예를 들어 Django 4.2를 릴리스하는 경우:

   $ git checkout stable/4.2.x
   $ git pull
   $ python manage_translations.py robots_txt
   

9. django-announce 메일링 리스트와 Django Forum에 릴리스 공지를 게시하세요. 공지에는 블로그 글의 링크를 포함해야 합니다.

10. If this is a security release, publish the CVE metadata. (The checklist app generates JSON for this.):

    $ cve publish <cve-number> --cve-json-file <path-to-file>
    

11. If this is a security release, send a separate email to [e-mail]. Provide “Django” plus the CVE IDs in the subject line. The message body should include the vulnerability details, for example, the announcement blog post text. Include a link to the announcement blog post.

릴리스 이후 작업

거의 다 완료되었습니다! 이제 남은 일은 다음과 같습니다.

1. 사전 릴리스가 아닌 경우, django/__init__.py``의 ``VERSION 튜플을 다시 업데이트하여 다음 예정 릴리스 버전으로 증가시키세요. 예를 들어 4.1.1을 릴리스한 후에는 ``VERSION``을 ``VERSION = (4, 1, 2, ‘alpha’, 0)``로 업데이트합니다. (example commit).

2. alpha 릴리스인 경우:

   1. `Trac’s versions list <https://code.djangoproject.com/admin/ticket/versions>`__에 기능 릴리스 버전을 추가하세요.

   2. 새로 생성된 안정 브랜치에서 보안 브랜치를 새로 생성하세요. ``upstream``을 가져와 최신 상태로 업데이트하세요. 예를 들어 5.2 알파 릴리스 이후의 경우:

      $ git fetch upstream
      $ git checkout -b security/5.2.x upstream/stable/5.2.x
      $ git push origin -u security/5.2.x:security/5.2.x
      

3. final 릴리스인 경우:

   1. code.djangoproject.com의 trac.ini 파일에서 default_version 설정을 업데이트하세요(example PR).

   2. 현재 안정 브랜치를 업데이트하고 Trac의 `Django release process <https://code.djangoproject.com/#Djangoreleaseprocess>`_에서 사전 릴리스 브랜치를 제거하세요.

   3. djangoproject.com의 다운로드 페이지를 업데이트하세요(example PR).

   4. 이 최종 릴리스가 배포될 때 메인스트림 지원 종료(EOM) 및 지원 종료(EOL)가 예정된 이전 버전을 처리하세요.

      1. 블로그 글에 EOL 버전이 언급되도록 하세요. Example.

      2. EOL 안정 브랜치에 태그를 생성하고 해당 안정 브랜치를 삭제하세요.``scripts/archive_eol_stable_branches.py`` 헬퍼 스크립트를 확인하고 사용하세요.

4. 보안 릴리스인 경우, 해결된 문제의 세부 내용을 :doc:`/releases/security`에 업데이트하세요.

5. 사전 릴리스인 경우, 번역 카탈로그를 업데이트하세요:

   1. 최근에 릴리스된 안정 브랜치에서 새 브랜치를 만드세요:

      $ git checkout stable/A.B.x
      $ git checkout -b update-translations-catalog-A.B.x
      

   2. 릴리스 전용 가상 환경이 활성화되어 있는지 확인하고 다음을 실행하세요.

      $ cd django
      $ django-admin makemessages -l en --domain=djangojs --domain=django
      processing locale en
      

   3. 해당 안정 브랜치를 대상으로 pull request를 생성하고 승인되면 병합하세요.

   4. 업데이트된 소스 번역을 main 브랜치에 반영하세요(example commit).

6. rc 사전 릴리스인 경우, `Django Forum - Internationalization category <https://forum.djangoproject.com/c/internals/i18n/14>`_에서 예정된 릴리스의 번역 참여를 요청하세요.

VERSION 튜플 설정 시 참고 사항

Django의 버전 정보는 django/__init__.py``의 ``VERSION 튜플로 관리됩니다. 이 튜플은 다섯 개의 요소로 구성되며, 각 요소는 다음과 같습니다:

1. 메이저 버전

2. 마이너 버전

3. 마이크로 버전

4. 상태: “alpha”, “beta”, “rc”, “final” 중 하나

5. 시리즈 번호: alpha/beta/RC 패키지가 순차적으로 릴리스될 때 사용됩니다(예: “beta 1”, “beta 2” 등).

최종 릴리스의 경우 상태는 항상 “final”이며 시리즈 번호는 항상 0입니다. “alpha” 상태에서 시리즈 번호가 0이면 “pre-alpha”로 표시됩니다.

예시:

• (4, 1, 1, "final", 0) → “4.1.1”

• (4, 2, 0, "alpha", 0) → “4.2 pre-alpha”

• (4, 2, 0, "beta", 1) → “4.2 beta 1”