{"title":"Django 릴리스하는 방법","version":"6.1","locale":"ko","docname":"internals/howto-release-django","url":"/ko/6.1/internals/howto-release-django/","canonical":"https://djangodocs.dev/ko/6.1/internals/howto-release-django/","summary":"이 문서는 Django 릴리스 방법을 설명합니다. 변경 사항을 적용할 때는 이 지침을 최신 상태로 유지하세요! 이 문서의 목적은 규정하기보다는 설명하는 데 있으므로, 필요에 따라 자유롭게 간소화하거나 변경해도 됩니다. 다만, 변경 사항이 있다면 이 문서에도 반드시 반영하세요! 개요 Link…","html":"

Django 릴리스하는 방법Link to this heading#

\n

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

\n

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

\n
\n

개요Link to this heading#

\n

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

\n\n

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

\n
    \n

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

    2. \n

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

    3. \n

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

    4. \n

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

    \n
      \n

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

      2. \n

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

      3. \n
    \n
    5. \n

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

    6. \n

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

    7. \n

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

    8. \n

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

    9. \n

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

    10. \n

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

    11. \n
\n

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

\n\n
\n
\n

사전 요구 사항Link to this heading#

\n

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

\n\n
\n
\n

사전 릴리스 작업Link to this heading#

\n

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

\n
\n

보안 릴리스 10일 전(또는 그 이상)Link to this heading#

\n
    \n

  1. Reserve one CVE ID per security\nissue as follows. (Or, if you lack CNA credentials, email\ncna@djangoproject.com with a request.)

    \n
      \n

    • Enable virtual environment with cvelib installed.

      • \n

    • Export user information:

      \n
      Shell
      $ export CVE_USER=<user-email>@djangoproject.com CVE_ORG=DSF\n
      \n
      • \n

    • Reserve:

      \n
      Shell
      $ cve --interactive reserve <quantity>\n
      \n
      • \n
    \n
    2. \n

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

    3. \n
\n
\n
\n

보안 릴리스 일주일 전Link to this heading#

\n
    \n

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

    \n
    Shell
    $ gpg --clearsign --digest-algo SHA256 prenotification-email.txt\n
    \n
    2. \n

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

    \n
    Text
    Notice of upcoming Django security releases (3.2.24, 4.2.10 and 5.0.2)\n\nDjango versions 5.0.2, 4.2.10, and 3.2.24 will be released on Tuesday,\nFebruary 6th, 2024 around 1500 UTC. They will fix one security defect\nwith severity "moderate".\n\nFor details of severity levels, see:\nhttps://docs.djangoproject.com/en/dev/internals/security/#how-django-discloses-security-issues\n
    \n
    3. \n

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

    4. \n
\n
\n
\n

릴리스 며칠 전Link to this heading#

\n
    \n

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

    2. \n

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

    3. \n

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

    4. \n

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

    5. \n

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

    6. \n

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

    \n

    In addition to having a configured Transifex account, ensure that the tx\nCLI is available in your\nPATH. You can then fetch all translations since a given date by running:

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

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

    \n

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

    \n

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

    \n
    Shell
    $ 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"\n
    \n

    Lastly, commit the changed/added files (both .po and .mo) and create\na new PR targeting the stable branch of the corresponding release (example\nPR updating translations for 4.2).

    \n

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

    \n
    7. \n

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

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

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

    \n
    8. \n

  8. If this is the “dot zero” release of a new series, create a new branch from\nthe current stable branch in the django-docs-translations repository. For\nexample, when releasing Django 4.2:

    \n
    Shell
    $ git checkout -b stable/4.2.x origin/stable/4.1.x\n$ git push origin stable/4.2.x:stable/4.2.x\n
    \n
    9. \n

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

    10. \n
\n
\n

기능 동결 며칠 전Link to this heading#

\n

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

\n

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

\n
    \n

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

    2. \n

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

    3. \n

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

    4. \n

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

    5. \n

  5. Advance the deprecation warnings (example commit).

    6. \n

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

    7. \n
\n

Concrete examples for past feature release bootstrap branches: 5.2 bootstrap, 5.1 bootstrap, 5.0 bootstrap.

\n
\n
\n
\n
\n

기능 동결 작업Link to this heading#

\n
    \n

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

    2. \n

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

    3. \n

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

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

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

    \n
    4. \n

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

    \n

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

    \n
    5. \n

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

    \n
    6. \n

  6. Add the new branch to Read the Docs. Since the automatically\ngenerated version names (“stable-A.B.x”) differ from the version names used\nin Read the Docs (“A.B.x”), update the Read the Docs config for the version\nto point to the slug A.B.x and set it as active. See more details.

    7. \n

  7. Create a PR on PyPI proposing the new Trove classifier.\nFor example Framework :: Django :: 5.2.

    8. \n

  8. Update the current branch under active development and add pre-release\nbranch in the Django release process on Trac.

    9. \n

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

    10. \n
\n
\n
\n

실제 릴리스 진행Link to this heading#

\n

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

\n
    \n

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

    \n
    2. \n

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

    \n
      \n

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

      2. \n

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

      3. \n
    \n
    3. \n

  3. Regenerate a fresh, dedicated virtual environment for the release tools\nusing a cooldown:

    \n
    Shell
    $ python -m pip install build twine --uploaded-prior-to=P7D\n
    \n
    4. \n

  4. A release always begins from a release branch, so you should make sure\nyou’re on an up-to-date stable branch. For example:

    \n
    Shell
    $ git checkout stable/4.1.x\n$ git pull\n
    \n
    5. \n

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

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

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

    \n

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

    \n
    6. \n

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

    \n
      \n

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

      2. \n

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

      3. \n
    \n
    7. \n
\n
\n

아티팩트 빌드하기Link to this heading#

\n\n
    \n

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

    \n
    Shell
    $ git tag --sign --message="Tag 4.1.1" 4.1.1\n
    \n

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

    \n
    2. \n

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

    3. \n

  3. Run python -m build to generate the release packages. This will create\nthe release artifacts (tarball and wheel) in a dist/ directory.

    4. \n

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

    \n
    Shell
    $ cd dist\n$ md5sum *\n$ sha1sum *\n$ sha256sum *\n
    \n
    5. \n

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

    \n
    Text
    This file contains MD5, SHA1, and SHA256 checksums for the source-code\ntarball and wheel files of Django <<VERSION>>, released <<DATE>>.\n\nTo use this file, you will need a working install of PGP or other\ncompatible public-key encryption software. You will also need to have\nthe Django release manager's public key in your keyring. This key has\nthe ID ``XXXXXXXXXXXXXXXX`` and can be imported from GitHub, for example,\nif using the open-source GNU Privacy Guard implementation of PGP:\n\n    curl https://github.com/<<RELEASE MANAGER GITHUB USERNAME>>.gpg | gpg --import -\n\nOnce the key is imported, verify this file:\n\n    gpg --verify <<THIS FILENAME>>\n\nOnce you have verified this file, you can use normal MD5, SHA1, or SHA256\nchecksumming applications to generate the checksums of the Django\npackage and compare them to the checksums listed below.\n\nRelease packages\n================\n\nhttps://www.djangoproject.com/download/<<VERSION>>/tarball/\nhttps://www.djangoproject.com/download/<<VERSION>>/wheel/\n\nMD5 checksums\n=============\n\n<<MD5SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<MD5SUM>>  <<RELEASE WHL FILENAME>>\n\nSHA1 checksums\n==============\n\n<<SHA1SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<SHA1SUM>>  <<RELEASE WHL FILENAME>>\n\nSHA256 checksums\n================\n\n<<SHA256SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<SHA256SUM>>  <<RELEASE WHL FILENAME>>\n
    \n
    6. \n

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

    7. \n
\n
\n
\n
\n

릴리스 공개하기Link to this heading#

\n

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

\n
    \n

  1. Create a new Release entry in the djangoproject.com’s admin. If this is a\nsecurity release, this should be done 15 minutes before the announced\nrelease time, no sooner:

    \n
    \n
    버전

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

    \n
    \n
    Is active

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

    \n
    \n
    LTS

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

    \n
    \n
    날짜

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

    \n
    \n
    아티팩트

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

    \n
    \n
    \n
    2. \n

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

    3. \n

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

    \n
    4. \n

  4. Generate a new token for this release on PyPI, and store it in .pypirc\nas shown above.

    5. \n

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

    \n
    Shell
    $ twine upload --repository django dist/*\n
    \n
    6. \n

  6. On PyPI, revoke the token you just created.

    7. \n

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

    8. \n

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

    \n
    Shell
    $ git push\n$ git push --tags\n
    \n
    9. \n

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

    10. \n

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

    \n

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

    \n
    Shell
    $ git checkout stable/4.2.x\n$ git pull\n$ python manage_translations.py robots_txt\n
    \n
    11. \n

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

    12. \n

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

    \n
    Shell
    $ cve publish <cve-number> --cve-json-file <path-to-file>\n
    \n
    13. \n

  13. If this is a security release, send a separate email to\noss-security@lists.openwall.com. Provide “Django” plus the CVE IDs in\nthe subject line. The message body should include the vulnerability details,\nfor example, the announcement blog post text. Include a link to the\nannouncement blog post.

    14. \n
\n
\n
\n

릴리스 이후 작업Link to this heading#

\n

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

\n
    \n

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

    2. \n

  2. alpha 릴리스인 경우:

    \n
      \n

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

      2. \n

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

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

  3. final 릴리스인 경우:

    \n
      \n

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

      2. \n

    2. Update the current stable branch and remove the pre-release branch in the\nDjango release process on Trac.

      3. \n

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

      4. \n

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

      \n
        \n

      1. Ensure that the EOL versions are mentioned in the blog post. See\nexample announcement.

        2. \n

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

        3. \n
      \n
      5. \n
    \n
    4. \n

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

    5. \n

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

    \n
      \n

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

      \n
      Shell
      $ git checkout stable/A.B.x\n$ git checkout -b update-translations-catalog-A.B.x\n
      \n
      2. \n

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

      \n
      Shell
      $ cd django\n$ django-admin makemessages -l en --domain=django\nprocessing locale en\n$ django-admin makemessages -l en --domain=djangojs\nprocessing locale en\n
      \n
      3. \n

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

      4. \n

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

      5. \n
    \n
    6. \n

  6. If this was an alpha pre-release, coordinate with the maintainer of\nasgiref to determine when to raise the minimum version before the\nfinal release. For the backport, add an upper bound on the next major\nversion (example commits:\nmain,\nbackport).

    7. \n

  7. If this was an rc pre-release, call for translations for the upcoming\nrelease in the Django Forum - Internationalization category.

    8. \n
\n
\n
\n

VERSION 튜플 설정 시 참고 사항Link to this heading#

\n

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

\n
    \n

  1. 메이저 버전

    2. \n

  2. 마이너 버전

    3. \n

  3. 마이크로 버전

    4. \n

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

    5. \n

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

    6. \n
\n

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

\n

예시:

\n\n
","rootId":"how-to-release-django","toc":[{"title":"개요","anchor":"overview","children":[]},{"title":"사전 요구 사항","anchor":"prerequisites","children":[]},{"title":"사전 릴리스 작업","anchor":"pre-release-tasks","children":[{"title":"보안 릴리스 10일 전(또는 그 이상)","anchor":"or-more-days-before-a-security-release","children":[]},{"title":"보안 릴리스 일주일 전","anchor":"a-week-before-a-security-release","children":[]},{"title":"릴리스 며칠 전","anchor":"a-few-days-before-any-release","children":[{"title":"기능 동결 며칠 전","anchor":"a-few-days-before-a-feature-freeze","children":[]}]}]},{"title":"기능 동결 작업","anchor":"feature-freeze-tasks","children":[]},{"title":"실제 릴리스 진행","anchor":"actually-rolling-the-release","children":[{"title":"아티팩트 빌드하기","anchor":"building-the-artifacts","children":[]}]},{"title":"릴리스 공개하기","anchor":"making-the-release-s-available-to-the-public","children":[]},{"title":"릴리스 이후 작업","anchor":"post-release","children":[]},{"title":"VERSION 튜플 설정 시 참고 사항","anchor":"notes-on-setting-the-version-tuple","children":[]}],"breadcrumbs":[{"docname":"internals/index","title":"Django 내부 구조","url":"/ko/6.1/internals/"}],"prev":{"docname":"internals/git","title":"Django 소스 코드 저장소","url":"/ko/6.1/internals/git/"},"next":null,"formats":{"html":"/ko/6.1/internals/howto-release-django/","markdown":"/ko/6.1/internals/howto-release-django.md","json":"/ko/6.1/internals/howto-release-django.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/internals/howto-release-django.txt","official":"https://docs.djangoproject.com/ko/6.1/internals/howto-release-django/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}