Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 101 – 파이썬 릴리스 실전 101

Author:
Barry Warsaw <barry at python.org>, Guido van Rossum <guido at python.org>
Status:
Active
Type:
Informational
Created:
22-Aug-2001
Post-History:

Replaces:
102
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

파이썬 릴리스를 만드는 것은 짜릿하면서도 정신없는 과정입니다. “고양이 떼몰이”라는 표현을 들어보셨습니까? 갓 다듬은 발톱으로 여러분의 맨살에 단단히 매달린 그 친구들 몇 마리를 등에 짊어진 채, 가르릉거리는 그 작은 생명체들에게 안장까지 얹어 마을로 몰고 가려 한다고 상상해 보십시오. 그래도 귀엽기는 하다고, 스스로를 다독여 봅니다.

사실 이건 약간의 과장입니다 😉 파이썬 릴리스 과정은 지난 몇 년간 꾸준히 개선되었고, 이제는 놀라운 우리 커뮤니티의 도움으로 그리 어렵지 않습니다. 이 PEP는 파이썬 릴리스를 만드는 데 필요한 모든 단계를 한곳에 모으려 시도합니다. 이제 대부분의 단계는 자동화되어 있거나 자동화의 안내를 받으므로, 이 목록을 수동으로 따라갈 필요는 더 이상 없습니다.

필요한 것들

릴리스 관리자로서 접근해야 할 자원이 많습니다. 아마도 완전할 목록을 아래에 제시합니다.

  • GPG 키.

    3.14 이전 버전의 Python 릴리스는 GPG로 디지털 서명되어 있으므로, 이를 위해서는 키가 필요하며, 바라건대 이 키는 다른 릴리스 관리자 중 최소 한 명과 “신뢰망(web of trust)”으로 연결되어 있어야 합니다.

    Note

    이 PEP의 GPG 지침은 Python 3.14 및 이후 버전에서는 무시해도 됩니다. 자세한 내용은 PEP 761을 참조하십시오.

  • 소프트웨어 모음:
    • python/release-tools 저장소의 체크아웃. 여기에는 먼저 의존성을 설치할 때 필요한 requirements.txt파일이 들어 있습니다. 그런 다음 저장소에 있는 스크립트를 실행할 수 있으며, 이는 이 PEP의 뒷부분에서 다룹니다.
    • Misc/NEWS를 관리하는 도구인 blurb. pip install로 설치할 수 있습니다.
  • 파일을 업로드할 서버에 대한 접근 권한:
    • 다운로드 파일을 호스팅하는 서버인 downloads.nyc1.psf.io, 그리고
    • 문서를 호스팅하는 서버인 docs.nyc1.psf.io입니다.
  • python/cpython에 대한 관리자 권한과 Release Managers team의 멤버십.
  • “API 키”를 포함한 www.python.org의 관리자 계정.
  • python/peps 저장소에 대한 쓰기 권한.

    이 글을 읽고 계신다면 아마 이미 이것을 가지고 계실 것입니다—어떤 릴리스 관리자든 첫 번째 임무는 릴리스 일정을 초안하는 것입니다. 하지만 이제 막 지원하신 거라면… 안됐습니다! 아, 그러니까, 축하드립니다!

  • python-cabal이라고 불릴 수도 있고 아닐 수도 있는, 초특급 비밀 릴리스 관리자 메일링 리스트 구독. 이에 대해 Barry에게 문의하십시오.
  • 릴리스에 서명할 때 사용할 @python.org 이메일 주소. postmaster@에 주소를 요청하십시오. 전체 계정을 받거나, 주요 이메일 제공업체에 정상적으로 보이도록 이 주소에서 이메일을 보낼 수 있는 리디렉션 별칭과 SMTP 자격 증명을 받을 수 있습니다.
  • Python Security Response Team에 추가되십시오.

릴리스의 종류

만들어야 할 릴리스에는 여러 종류가 있습니다. 여기에는 다음이 포함됩니다:

  • alpha
  • begin beta (beta 1 또는 new branch라고도 함)
  • beta 2+
  • release candidate 1
  • release candidate 2+
  • final
  • new branch
  • begin bugfix mode
  • begin security-only mode
  • end-of-life

이러한 릴리스 유형 중 일부는 실제로 하나 이상의 릴리스 브랜치를 포함합니다. 특히, new branch는 새로운 기능 릴리스 주기가 시작되는 릴리스 주기상의 시점입니다. CPython Git 저장소의 현재 구성에서, main 브랜치는 항상 새로운 기능의 대상이 됩니다. 다음 기능 릴리스의 릴리스 주기 중 어느 시점에서, new branch 릴리스가 이루어지며, 이는 현재 진행 중인 기능 릴리스(3.n.0)의 안정화 및 이후 유지 관리를 위한 새로운 별도 브랜치를 생성하고, main 브랜치는 새로운 버전(결국 3.n+1.0으로 릴리스될 버전)을 빌드하도록 수정됩니다. new branch 릴리스 단계는 릴리스 주기 중 여러 시점 중 하나에서 발생할 수 있지만, 현재 관행은 첫 번째 베타 릴리스가 예정된 릴리스의 기능 코드 마감 시점에 발생하는 것입니다.

다음에 이어지는 설명에서, 릴리스 유형에 특정한 단계는 그에 따라 표시되며, 현재로서는 new branch와 final이 있습니다.

릴리스를 만드는 방법

다음은 Python 릴리스를 만들기 위해 수행되는 단계입니다. 일부 단계는 자동화할 수 있는 부분이 거의 없기 때문에(예: NEWS 항목 작성) 다른 단계보다 더 모호합니다. 어떤 단계가 보통 전문가(An Expert)에 의해 수행되는 경우, 그 전문가의 역할이 명시되어 있습니다. 그렇지 않으면, 해당 단계는 릴리스를 수행하는 지정된 사람인 릴리스 관리자(RM)가 수행하는 것으로 가정하십시오. 역할과 현재 담당 전문가는 다음과 같습니다:

Note

RM은 릴리스 전날 전문가들에게 연락할 것을 강력히 권장합니다. 세계는 둥글고 모두가 서로 다른 시간대에 살고 있으므로, RM은 전문가들이 바이너리 릴리스를 만들 수 있도록 충분한 시간을 두고 릴리스 태그가 생성되도록 해야 합니다.

모든 전문가가 자신의 바이너리를 업데이트하기 전에는 (웹사이트를 업데이트하고 공지를 발송하는 방식으로) 릴리스를 공개해서는 안 됩니다. Windows나 Mac 담당 전문가가 드물게 연락 두절(MIA) 상태인 경우, “(플랫폼) 바이너리는 곧 제공될 예정입니다”라는 메시지를 추가하고 진행해도 됩니다.

아래 예제에서는 다음과 같은 규칙을 사용합니다. 릴리스 번호가 주어질 때는 3.X.YaN 형식이며, 예를 들어 Python 3.13.0 alpha 3의 경우 3.13.0a3이고, 여기서 “a” == alpha, “b” == beta, “rc” == release candidate입니다.

릴리스 태그의 이름은 v3.X.YaN입니다. 마이너 릴리스 유지보수 브랜치의 이름은 3.X입니다.

가능한 한 릴리스는 run_release.py 스크립트에 의해 자동화되고 안내되며, 이 스크립트는 별도의 저장소인 python/release-tools에서 확인할 수 있습니다. 이는 다음 단계 중 많은 부분을 자동화하여 도움을 주며, 일부 수동 단계를 수행하도록 안내합니다.

  • Discord에 로그인하여 Python Core Devs 서버에 참여하십시오. 다른 RM에게 초대를 요청하십시오.

    아마도 전 세계의 다른 사람들과 조율해야 할 것입니다. 이 소통 채널이 저희가 만나기로 정한 곳입니다.

  • 치명적인 버그가 있는지 확인하십시오.

    https://github.com/python/cpython/issues 에 가서 이번 릴리스를 막을 수 있는 열려 있는 버그가 있는지 찾아보십시오. 관련 있는 레이블 두 가지를 살펴보게 됩니다:

    release-blocker
    릴리스를 완전히 멈춰 세웁니다. 열려 있는 릴리스 차단 버그가 하나라도 있으면 어떠한 릴리스도 만들 수 없습니다.
    deferred-blocker
    이번 릴리스는 막지 않지만, 이후 릴리스는 막게 됩니다. 열려 있는 지연 차단 버그가 하나라도 있으면 최종 릴리스나 후보 릴리스를 만들 수 없습니다.

    릴리스 차단 버그들을 검토하여 해결하거나, 지연 차단으로 낮추거나, 릴리스를 중단하고 커뮤니티의 도움을 요청하십시오. 최종 릴리스나 후보 릴리스를 만드는 경우, 열려 있는 지연 차단 버그에 대해서도 동일하게 처리하십시오.

  • 안정적인 빌드봇들을 확인하십시오.

    https://buildbot.python.org/all/#/release_status 로 이동하십시오.

    만들고 있는 릴리스에 대한 빌드봇을 살펴보십시오. 오프라인 상태인 것은 무시하십시오(또는 커뮤니티에 알려 재시작할 수 있도록 하십시오). 남은 것이 (대부분) 초록색 빌드봇이라면 진행해도 좋습니다. 오프라인이 아닌 빨간색 빌드봇이 있다면, 문제가 해결될 때까지 릴리스를 보류하는 것이 좋습니다. 문제를 검토하고, 알파, 베타, 최종 릴리스 중 무엇을 만들고 있는지를 고려하여 판단하십시오.

  • 릴리스 클론을 만드십시오.

    GitHub의 CPython 저장소 포크에서 그 안에 릴리스 브랜치를 생성하십시오(이제부터 “릴리스 클론”이라고 부릅니다). CPython 개발에 사용하는 것과 동일한 GitHub 포크를 사용할 수 있습니다. Python 개발자 가이드에서 권장하는 표준 설정을 사용하면, 여러분의 포크는 origin으로, 표준 CPython 저장소는 upstream으로 지칭됩니다. 여러분은 릴리스에 태그를 붙이는 것을 포함한 릴리스 엔지니어링 작업을 수행하기 위해 자신의 포크에 있는 브랜치를 사용하며, 바이너리를 만드는 다른 전문가들과 공유하기 위해서도 이 브랜치를 사용합니다.

    최종또는 릴리스 후보 2 이상릴리스의 경우, 지난 rc 이후 병합된 모든 변경 사항 중 일부를 다음 rc 또는 최종 릴리스를 위해 체리픽할 예정이라면, 가장 최근의 릴리스 후보 태그(즉 v3.8.0rc1)에서 시작하는 릴리스 엔지니어링 브랜치를 생성해야 합니다. 그런 다음 필요에 따라 표준 릴리스 브랜치의 변경 사항을 릴리스 엔지니어링 브랜치로 체리픽한 후 평소대로 진행하십시오. 이전 rc 이후의 모든 변경 사항을 가져올 예정이라면, 평소대로 진행해도 됩니다.

  • 릴리스 클론의 현재 브랜치가 릴리스하려는 브랜치인지 확인하십시오(git status).
  • 버전 번호를 지정하여 blurb release <version>을 실행하십시오 (예: blurb release 3.4.7rc1). 이는 최근의 모든 뉴스 블러브를 이 릴리스의 버전 번호로 표시된 단일 파일로 병합합니다.
  • Lib/pydoc-topics.py를 재생성하십시오.

    아직 Doc 디렉터리에 있는 상태에서 다음을 실행하십시오:

    make pydoc-topics
cp build/pydoc-topics/topics.py ../Lib/pydoc_data/topics.py
  • pydoc_topics.py에 대한 변경 사항을 커밋하십시오(그리고 문서에서 수행한 수정 사항도 포함하십시오).
  • configure 또는 다른 Autoconf 생성 파일이 더 새롭거나 더 오래된 버전으로 마지막에 커밋되어 가짜이거나 해로운 차이가 포함되어 있을 수 있으므로, 현재 승인된 표준 버전을 사용하여 autoconf를 실행하는 것을 고려하십시오. 현재 Autoconf 2.71이 사실상의 표준입니다. 차이가 있으면 커밋하십시오.
  • Doc/tools/extensions/pyspecific.py의 SOURCE_URI가 Git 저장소에서 올바른 브랜치(main 또는 3.X)를 가리키는지 확인하십시오. 새 브랜치 릴리스의 경우, 파일에서 브랜치를 main에서 생성하려는 새 릴리스 브랜치(3.X)로 변경하십시오.
  • 릴리스 스크립트를 통해 버전 번호를 올리십시오:
    .../release-tools/release.py --bump 3.X.YaN

    참고: X, Y, N은 정수여야 합니다. a는 a, b, rc 중 하나여야 합니다(예: 3.4.3rc1). 최종 릴리스에서는 aN을 생략합니다(3.4.3). 새 버전의 첫 릴리스에서는 Y가 0이어야 합니다(3.6.0).

    이는 다양한 릴리스 번호 업데이트를 자동화하지만, 몇몇 파일은 직접 수정해야 합니다. $EDITOR 환경 변수가 올바르게 설정되어 있다면, release.py가 수정해야 할 파일들이 담긴 편집기 창을 띄워줍니다.

    blurb가 생성한 Misc/NEWS 파일을 검토하고 필요에 따라 수정하십시오.

  • 모든 변경 사항이 커밋되었는지 확인하십시오. (release.py --bump는 변경 사항을 대신 커밋해 주지 않습니다.)
  • 최종 메이저 릴리스의 경우, Doc/whatsnew/3.X.rst의 첫 번째 단락을 편집하여 실제 릴리스 날짜를 포함시키십시오. 예를 들어 “Python 2.5 was released on August 1, 2003.”와 같이 작성합니다. 알파나 베타 릴리스의 경우에는 이를 편집할 필요가 없습니다.
  • 이 디렉터리에서 git status를 실행하십시오.

    어떤 파일도 보이지 않아야 합니다. 즉, 작업 디렉터리에 커밋되지 않은 변경 사항이 없어야 합니다.

  • 3.X.YaN에 대한 릴리스에 태그를 지정하십시오.:
    .../release-tools/release.py --tag 3.X.YaN

    이는 저장소의 릴리스 태그가 여러분의 GPG 키로 서명되도록 -s 옵션과 함께 git tag 명령을 실행합니다. 프롬프트가 표시되면 릴리스 타르볼 등에 서명할 때 사용하는 개인 키를 선택하십시오.

  • 보안 전용 모드 시작 및 수명 종료 릴리스의 경우, 두 파일을 검토하고 모든 활성 브랜치에서 이에 맞춰 버전을 업데이트하십시오.
  • GitHub 포크의 원격 릴리스 브랜치로 커밋을 푸시하십시오.:
    # Do a dry run first.
git push --dry-run --tags origin
# Make sure you are pushing to your GitHub fork,
# *not* to the main python/cpython repo!
git push --tags origin
  • python/release-tools에서 build-release 워크플로로 이동하여 “Run workflow”를 선택하고, 방금 생성한 태그의 세부 정보를 입력하십시오. 이는 다음 단계를 수행합니다:
    • 소스 gzip 및 xz 타르볼을 생성합니다.
    • 문서 tar 및 zip 파일을 생성합니다.
    • 완전히 깨끗한, 처음부터 새로 빌드한 것이 회귀 테스트를 통과하는지 확인하기 위해 소스 타르볼을 검사합니다.
    • 전문가가 필요하지 않은 플랫폼용 바이너리를 빌드하고 테스트합니다.

    결과로 생성된 아티팩트는 GitHub 워크플로의 요약 페이지에 첨부됩니다. 소스 tarball을 사용할 수 있게 되면, 이를 다운로드하고 압축을 풀어서 상태가 합리적인지, 남아 있는 .pyc 파일이 없는지 등을 확인하십시오.

    테스트가 통과하면 tarball이 문제없다고 안심해도 좋습니다. 테스트 중 일부가 실패하거나 방금 압축을 푼 디렉터리에 대해 뭔가 이상해 보이는 점이 있다면, 지금 멈추고 무엇이 문제인지 파악하는 편이 낫습니다.

  • 전문가들에게 바이너리 빌드를 시작해도 된다고 알리십시오.

Warning

STOP: 이 시점에서는 릴리스를 생성하기 위해 다른 전문가들로부터 “청신호”를 받아야 합니다. 다만 기다리는 동안 할 수 있는 일들이 있으니, 다음 STOP에 도달할 때까지 계속 읽으십시오.

  • WE는 .azure-pipelines/windows-release/에 있는 Azure Pipelines 빌드 스크립트를 사용해 Windows 파일을 생성하고 게시하며, 현재 https://dev.azure.com/Python/cpython/_build?definitionId=21 에 설정되어 있습니다.

    빌드 프로세스는 여러 단계로 실행되며, 각 단계의 출력물은 다운로드 가능한 아티팩트로 제공됩니다. 단계는 다음과 같습니다:

    • 프로파일 기반 최적화 실행을 포함하여 바이너리의 모든 변형(32비트, 64비트, 디버그/릴리스)을 컴파일합니다.
    • PSF의 인증서로 모든 바이너리에 코드 서명을 합니다.
    • python.org, nuget.org, 임베더블 배포판 및 Windows 스토어용 패키지를 생성합니다.
    • 설치 프로그램에 대한 기본 검증을 수행합니다.
    • python.org와 nuget.org에 패키지를 업로드하고, 다운로드 캐시를 비운 뒤 테스트 다운로드를 실행합니다.

    업로드가 완료되면, WE는 빌드 로그에서 생성된 해시를 복사하여 RM에게 이메일로 보냅니다. Windows Store 패키지는 WE에 의해 https://partner.microsoft.com/dashboard/home 에 수동으로 업로드됩니다.

  • ME는 Mac 설치 프로그램 패키지를 빌드하여 GPG 서명 파일과 함께 downloads.nyc1.psf.io에 업로드합니다.
  • build-release 워크플로우로 빌드된 모든 파일을 서명, SBOM 등과 함께 downloads.nyc1.psf.io상의 홈 디렉터리로 scp 또는 rsync하십시오.

    파일 업로드가 완료되기를 기다리는 동안, 나머지 작업을 계속 진행할 수 있습니다. Discord와/또는 discuss.python.org의 사람들에게 파일 업로드가 완료되는 대로 다운로드해 달라고 요청하여, 각자의 플랫폼에서도 테스트할 수 있도록 할 수 있습니다.

  • 이제 downloads.nyc1.psf.io로 이동하여 모든 파일을 그곳의 제자리로 옮겨야 합니다. 우리의 정책은 모든 Python 버전이 각자의 디렉터리를 가지되, 각 디렉터리에는 해당 버전의 모든 릴리스가 포함된다는 것입니다.
    • downloads.nyc1.psf.io에서 cd /srv/www.python.org/ftp/python/3.X.Y를 실행하여, 필요하면 생성하십시오. 그것이 downloads 그룹 소유이며 그룹 쓰기 가능인지 확인하십시오.
    • 위에서 홈 디렉터리에 업로드한 파일들을 가져와 릴리스 디렉터리로 옮기십시오. Win/Mac 바이너리는 보통 전문가들 스스로에 의해 그곳에 놓입니다.

      그것들이 누구나 읽을 수 있는지 확인하십시오. 또한 그룹 쓰기 가능이어야 하며, downloads 그룹이 소유해야 합니다.

    • 파일이 손상 없이 업로드되었는지 확인하려면 gpg --verify를 사용하십시오.
    • 이것이 final 또는 rc 릴리스인 경우: 문서 zip 파일과 tarball을 /srv/www.python.org/ftp/python/doc/3.X.Y[rcA]로 이동시키고, 필요하다면 디렉터리를 생성한 다음, .../doc 안의 “current” 심볼릭 링크가 해당 디렉터리를 가리키도록 조정하십시오. 다만 이전 버전에 대한 유지보수 릴리스를 배포하는 경우에는 current 링크를 변경하지 않도록 주의하십시오.
    • 이것이 final 또는 rc 릴리스인 경우(유지보수 릴리스라도), docs.nyc1.psf.io의 /srv/docs.python.org/release/3.X.Y[rcA]에도 HTML 문서를 압축 해제하십시오. 파일이 docs 그룹에 속하고 그룹 쓰기 가능(group-writeable) 상태인지 확인하십시오.
    • 문서와 다운로드 모두 캐싱 CDN 뒤에 있다는 점에 유의하십시오. 웹사이트를 통해 아카이브를 다운로드한 후에 해당 아카이브를 변경한 경우, 다음과 같이 CDN의 오래된 데이터를 제거해야 합니다:
      curl -X PURGE https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tar.xz

      사람들이 릴리스 파일을 찾아보는 데 디렉터리 목록을 사용하므로, 항상 디렉터리 목록의 캐시를 제거해야 합니다:

      curl -X PURGE https://www.python.org/ftp/python/3.12.0/
  • 지나치게 신중을 기하고 싶다면, 릴리스에 대해 완전히 깨끗한 테스트를 수행하십시오. 여기에는 www.python.org에서 tarball을 다운로드하는 것도 포함됩니다.

    md5 체크섬이 일치하는지 확인하십시오. 그런 다음 tarball을 압축 해제하고, 깨끗한 상태에서 make test를 수행하십시오:

    make distclean
./configure
make test

    회귀 테스트 스위트가 통과하는지 확인하기 위함입니다. 통과하지 않는다면, 어딘가에서 실수를 저지른 것입니다!

Warning

멈추고 확인하십시오:

  • WE로부터 승인(green light)을 받았습니까?
  • ME로부터 승인(green light)을 받았습니까?

초록색이면 릴리스 엔지니어링 브랜치를 메인 저장소로 다시 병합할 시점입니다.

  • GitHub로 변경 사항을 푸시하려면, 일시적으로 관리자에 대한 브랜치 보호를 비활성화해야 합니다. Settings | Branches 페이지로 이동하십시오:

    https://github.com/python/cpython/settings/branches

    릴리스 중인 브랜치의 설정을 “Edit”하십시오. 이렇게 하면 해당 브랜치의 설정 페이지가 로드됩니다. “Include administrators” 상자의 체크를 해제하고 하단의 “Save changes” 버튼을 누르십시오.

  • 릴리스 클론을 메인 개발 저장소로 병합하십시오:
    # Pristine copy of the upstream repo branch
git clone git@github.com:python/cpython.git merge
cd merge

# Checkout the correct branch:
# 1. For feature pre-releases up to and including a
#    **new branch** release, i.e. alphas and first beta
#   do a checkout of the main branch
git checkout main

# 2. Else, for all other releases, checkout the
#       appropriate release branch.
git checkout 3.X

# Fetch the newly created and signed tag from your clone repo
git fetch --tags git@github.com:your-github-id/cpython.git v3.X.YaN
# Merge the temporary release engineering branch back into
git merge --no-squash v3.X.YaN
git commit -m 'Merge release engineering branch'
  • 이것이 새 브랜치릴리스인 경우, 즉 첫 번째 베타인 경우, 이제 새 릴리스 브랜치를 생성하십시오:
    git checkout -b 3.X

    새 릴리스 브랜치를 설정하는 데 필요한 단계를 수행하십시오. 포함되는 작업은 다음과 같습니다:

    • README.rst에서 main에 대한 모든 참조를 새 브랜치로 변경하십시오. 특히 GitHub 저장소 URL이 그렇습니다.
  • 모든 릴리스에 대해, 릴리스 스크립트로 안내되는 릴리스 후 단계를 수행하십시오:
    .../release-tools/release.py --done 3.X.YaN
  • final이나 release candidate 2+ 릴리스의 경우, 병합 후 정리 작업이 필요할 수 있습니다. 최상위 README.rst 및 include/patchlevel.h 파일을 확인하여, 이제 진행 중인 개발을 위해 원하는 릴리스 후 값들이 반영되었는지 확인하십시오. 패치레벨은 +dev가 붙은 릴리스 태그여야 합니다. 또한, 이번 릴리스를 위해 표준 릴리스 브랜치에서 릴리스 엔지니어링 브랜치로 체리픽한 변경 사항이 있다면, 이제 Misc/NEWS.d/next 디렉터리에서 현재 작업 중인 릴리스로 체리픽된 각 blurb 항목을 수동으로 제거해야 합니다. 해당 blurb 항목은 이제 새 릴리스의 병합된 x.y.z.rst 파일에 포함되었기 때문입니다. 그렇지 않으면 blurb 항목이 changelog.html 파일에 두 번 나타나는데, Python next 아래에 한 번, x.y.z 아래에 다시 한 번 나타납니다.
  • 이 변경 사항을 검토하고 커밋하십시오.:
    git commit -m 'Post release updates'
  • 이것이 new branch 릴리스(예: 첫 번째 베타)인 경우, 다음 기능 릴리스를 위한 개발을 시작하도록 main 브랜치를 업데이트하십시오. 완료되면 main 브랜치는 이제 Python X.Y+1을 빌드합니다.
    • 먼저 main을 다음 릴리스, 즉 X.Y+1.a0으로 설정하십시오.:
      git checkout main
.../release-tools/release.py --bump 3.9.0a0
    • README.rst의 모든 버전 참조를 수정하십시오.
    • Doc/tutorial/interpreter.rst를 수정하십시오(‘[Pp]ython3x’에 대한 참조 두 개, ‘Python 3.x’에 대한 참조 하나, 배너의 날짜도 일치시켜야 함).
    • Doc/tutorial/stdlib.rst와 Doc/tutorial/stdlib2.rst를 수정하십시오. 각각 ‘[Pp]ython3x’에 대한 참조가 하나씩 있습니다.
    • 새 whatsnew/3.x.rst 파일을 추가하고(상단 근처의 주석과 이전 파일에서 복사한 최상위 섹션 포함), whatsnew/index.rst의 toctree에 추가하십시오. 하지만 이전 릴리스에서 최초로 체크인된 whatsnew/3.x.rst는 릴리스마다 전파되는 blurb의 초기 중간 변경으로 인해 잘못되었을 수 있으니 주의하십시오! 이 악순환을 끊는 데 도움을 주십시오. 필요하다면 다음과 같이 변경하십시오.
      -For full details, see the :source:`Misc/NEWS` file.
+For full details, see the :ref:`changelog <changelog>`.
    • configure.ac의 버전 번호를 업데이트하고 autoconf를 다시 실행하십시오.
    • Doc/tools/extensions/pyspecific.py의 SOURCE_URI가 main을 가리키는지 확인하십시오.
    • python38을 참조하는 Windows 빌드의 버전 번호를 업데이트하십시오.:
      ls PC/pyconfig.h.in PCbuild/rt.bat | xargs sed -i 's/python3\(\.\?\)[0-9]\+/python3\19/g'
    • .github/ISSUE_TEMPLATE/의 bug.yml과 crash.yml 이슈 템플릿을 편집하여 “versions” 드롭다운에 새 브랜치를 추가하십시오.
    • 이 변경 사항을 main 브랜치에 커밋하십시오.:
      git status
git add ...
git commit -m 'Bump to 3.9.0a0'
  • 이 디렉터리에서 git status를 다시 실행하십시오.

    아무 파일도 표시되지 않아야 합니다. 즉, 작업 디렉터리에 커밋되지 않은 변경 사항이 없어야 합니다.

  • main 저장소에 커밋하고 푸시하십시오.:
    # Do a dry run first.

# For feature pre-releases prior to a **new branch** release,
#   i.e. a feature alpha release:
git push --dry-run --tags  git@github.com:python/cpython.git main
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git main

# For a **new branch** release, i.e. first beta:
git push --dry-run --tags  git@github.com:python/cpython.git 3.X
git push --dry-run --tags  git@github.com:python/cpython.git main
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git 3.X
git push --tags  git@github.com:python/cpython.git main

# For all other releases:
git push --dry-run --tags  git@github.com:python/cpython.git 3.X
# If it looks OK, take the plunge.  There's no going back!
git push --tags  git@github.com:python/cpython.git 3.X
  • 이번이 새 브랜치 릴리스라면 새로 생성된 브랜치(3.X)에 대해 Branch protection rule을 추가하십시오. 이전 릴리스 브랜치(3.X-1)의 값을 확인하고 이를 템플릿으로 사용하십시오. https://github.com/python/cpython/settings/branches

    또한 GitHub 저장소에 3.x와 needs backport to 3.X 레이블을 추가하십시오. https://github.com/python/cpython/labels

  • 이제 GitHub에서 관리자에 대한 브랜치 설정 적용을 다시 활성화할 수 있습니다. Settings | Branch 페이지로 돌아가십시오.

    https://github.com/python/cpython/settings/branches

    릴리스 중인 브랜치의 설정에서 “Edit”을 클릭하십시오. “Include administrators” 상자를 다시 체크하고 하단의 “Save changes” 버튼을 누르십시오.

이제 웹사이트를 손볼 시간입니다. 죄송하지만, 이 과정은 거의 자동화되어 있지 않습니다.

이 단계들을 수행하려면 웹사이트를 편집할 권한이 있어야 합니다. 그 권한이 없다면, pydotorg@python.org로 연락하여 적절한 권한을 요청하십시오.

  • https://www.python.org/admin 에 로그인하십시오.
  • 릴리스를 위한 새 “release”를 생성하십시오. 현재 “Releases”는 “Downloads” 아래에 정렬되어 있습니다.

    가장 쉬운 방법은 기존 파이썬 릴리스 “페이지”에서 필드를 복사한 다음 필요한 부분을 수정하는 것입니다.

    릴리스를 설명할 때 Markdown 또는 reStructured Text를 사용할 수 있습니다. 전자는 덜 장황하고, 후자는 PEP를 참조하는 등의 작업에 멋진 통합 기능을 제공합니다.

    폼의 “Release page” 필드는 비워 두십시오.

  • 릴리스를 “Save”하십시오.
  • 릴리스에 다운로드 가능한 파일들을 채워 넣으십시오.

    여러분과 저의 친구인 Georg Brandl이 add_to_pydotorg.py라는 멋진 도구를 만들었습니다. 이 도구는 python/release-tools저장소에서 (release.py 옆에) 찾을 수 있습니다. 다음과 같이 downloads.nyc1.psf.io에서 이 도구를 실행합니다.:

    AUTH_INFO=<username>:<python.org-api-key> python add_to_pydotorg.py <version>

    이것은 <version>에 대한 올바른 다운로드 디렉터리를 순회하며, <version>으로 표시된 파일을 찾고, 이 파일들로 웹 사이트에서 올바른 “release”의 “Release Files”를 채웁니다. 실행할 때마다 해당 버전의 “Release Files”가 지워진다는 점에 유의하십시오. 어떤 디렉터리에서든 실행해도 되며, 파일이 변경되면 원하는 만큼 여러 번 실행해도 됩니다. dl-files의 홈 디렉터리에 사본을 보관하고 최신 상태로 유지하십시오.

    릴리스에 새로운 유형의 파일이 추가되면, 누군가 이 새 파일을 인식하도록 add_to_pydotorg.py를 업데이트해야 합니다. (파일 유형이 제거될 때도 add_to_pydotorg.py를 업데이트하는 것이 가장 좋습니다.)

    이 스크립트는 이 시점까지 Sigstore로 서명되지 않은 나머지 파일에도 모두 서명합니다. 다시 말하지만, 이런 일이 발생하면 이 작업에는 반드시 @python.org 주소를 사용하십시오. 더 자세한 내용: https://www.python.org/downloads/metadata/sigstore/

  • CDN이 파일이 없는 상태의 Downloads 페이지 버전을 이미 캐시한 경우, 다음을 사용하여 캐시를 무효화할 수 있습니다:
    curl -X PURGE https://www.python.org/downloads/release/python-XXX/
  • discuss.python.org에 공지를 작성하십시오. 이 부분은 자동화할 수 있는 것이 많지 않기 때문에 애매한 부분입니다. 이전 공지를 템플릿으로 사용할 수 있지만, 내용에 맞게 수정하십시오!
  • 또한 Python Insider blog에도 공지를 게시하십시오. 새 항목을 추가하려면 python/python-insider-blog로 이동하십시오.
  • release PEPs (예: 719)를 릴리스 날짜로 업데이트하십시오.
  • https://github.com/python/cpython/issues 의 레이블을 업데이트하십시오:
    • 다음 릴리스를 위해 deferred-blocker 이슈를 모두 다시 release-blocker로 전환하십시오.
    • 열린 이슈를 검토하십시오. 사람들에게 잊고 있던 쉬운 항목들을 고치도록 상기시키는 것 외에도, 숨어 있는 치명적인 버그를 발견할 수 있습니다.
  • 저장소 클론에서 원격 릴리스 클론 브랜치를 삭제할 수 있습니다.
  • 이것이 새 브랜치 릴리스인 경우, 개발 인프라의 여러 부분이 새 브랜치에 맞게 업데이트되었는지 확인해야 합니다. 여기에는 다음이 포함됩니다:
    • 새 브랜치에 대해 issue tracker를 업데이트하십시오: 버전 목록에 새 버전을 추가하십시오.
    • 새 브랜치와 버전을 반영하도록 python-releases.toml을 업데이트하십시오.
    • downloads page에서 지원되는 릴리스 표를 업데이트하는 PR을 생성하십시오 (python/pythondotorg#1302 참고).
    • 새 브랜치에 대해 buildbot이 정의되어 있는지 확인하십시오 (Łukasz 또는 Zach Ware에게 문의하십시오).
    • 필요에 따라 새 브랜치에 맞게 다양한 GitHub 봇이 업데이트되었는지 확인하십시오. 특히, 새 브랜치로의 백포팅이 제대로 작동하는지 확인하십시오 (core-workflow team에 문의하십시오).
    • main과 새 릴리스 브랜치의 가장 최근 커밋 이력을 검토하여, 릴리스 엔지니어링 단계 동안 main 브랜치에 병합되었을 수 있으나 릴리스 브랜치에도 있어야 하는 병합을 식별하여 백포트하십시오.
    • main과 새 릴리스 브랜치에 대한 새 PR에서 CI가 작동하는지, 그리고 릴리스 브랜치가 적절히 보호되어 있는지(직접 푸시 금지 등) 확인하십시오.
    • online docs가 제대로 빌드되는지 확인하십시오 (웹사이트에서 전체 빌드가 완료되기까지 최대 24시간이 걸릴 수 있습니다).

다음 단계는?

  • 확인하십시오! 사용자라고 가정하고 www.python.org에서 파일을 다운로드하여 Python을 빌드해 보십시오. 이 단계는 놓치기 너무 쉬우며, 여러 차례 쓸모없는 릴리스 파일을 만든 적이 있습니다. 한 번은 일반적인 서버 문제로 모든 파일이 원인 모를 손상을 입은 적이 있었고, 한 번은 소스 tarball이 잘못 빌드된 적이 있었으며, SF의 파일 업로드 과정에서 파일이 잘린 적도 한 번 이상 있었고, 그 밖에도 여러 사례가 있습니다.
  • 기뻐하십시오. 마시십시오. 즐거워하십시오. 이와 같은 PEP를 작성하십시오. 아니면 Guido처럼 휴가를 떠나십시오.

여러분은 방금 Python 릴리스를 만들었습니다!

수명 종료로 전환

현재 정책에 따르면, 릴리스 브랜치는 일반적으로 최초 릴리스 후 5년이 지나면 수명 종료 상태에 도달합니다. 이 정책은 Python Developer’s Guide에 더 자세히 설명되어 있습니다. 수명 종료에 도달하면, 릴리스 관리자인 여러분이 직접 수행하거나 다른 누군가가 수행하도록 확인해야 할 여러 작업이 있습니다. 이러한 작업에는 다음이 포함됩니다:

  • 아직 릴리스되지 않은 변경 사항을 게시하기 위해 선택적으로 최종 릴리스를 만듭니다.
  • 릴리스 브랜치의 현재 HEAD에 태그를 생성한 다음 CPython 저장소에서 브랜치를 삭제하여 릴리스 브랜치의 상태를 고정하십시오. 현재 HEAD는 해당 브랜치의 마지막 보안 릴리스이거나 그 이후여야 합니다:
    git fetch upstream
git tag --sign -m 'Final head of the former 3.3 branch' 3.3 upstream/3.3
git push upstream refs/tags/3.3
  • 모든 것이 문제없어 보이면 브랜치를 삭제하십시오. 이 작업에는 저장소 관리자 권한을 가진 사람의 도움이 필요할 수 있습니다:
    git push upstream --delete 3.3  # or perform from GitHub Settings page
  • python-releases.toml에서 브랜치 상태를 end-of-life로 설정하십시오.
  • developer’s guide에서 브랜치에 대한 참조를 업데이트하거나 제거하십시오.
  • issue tracker에서 릴리스를 폐기하십시오. 작업에는 다음이 포함됩니다:
    • 이 버전의 이슈를 다음 지원 버전으로 업데이트
    • 버전 목록에서 버전 레이블 제거
    • 폐기된 버전에 대한 needs backport to 레이블 제거
    • 이 브랜치용으로 표시된 열린 이슈를 검토하고 처리
  • end-of-life 배너를 추가하기 위해 온라인 문서의 최종 빌드를 실행하십시오.
  • 평소 사용하는 곳에 브랜치 폐기를 공지하십시오:
  • 은퇴를 즐기시고, 훌륭히 해낸 일의 성취감을 만끽하십시오!

Windows 참고 사항

Windows에는 MSI 설치 프로그램이 있고, Windows의 다양한 버전에는 “특수한 제약”이 있으며, Windows 설치 프로그램에는 미리 컴파일된 “외부” 바이너리(Tcl/Tk, expat 등)도 함께 포함되어 있습니다.

설치 프로그램은 Azure Pipeline의 일부로 테스트됩니다. 과거에는 이러한 단계들이 수동으로 수행되었습니다. 이는 후세를 위해 기록으로 남겨둡니다.

설치 프로그램을 업로드하는 것과 동시에, WE는 그것으로부터 Python을 두 번 설치합니다: 한 번은 설치 프로그램이 제안하는 기본 디렉터리에, 그리고 나중에는 이름에 공백이 포함된 디렉터리에 설치합니다. 각 설치마다 WE는 DOS 창에서 전체 회귀 테스트 스위트를 실행하며, -0 옵션을 사용할 때와 사용하지 않을 때 모두 실행합니다. 유지 보수 릴리스의 경우, WE는 업그레이드 설치가 성공하는지도 테스트합니다.

WE는 또한 Start -> Menu -> Python 그룹 아래에 생성된 모든 바로 가기를 시도해 봅니다. 이런 방식으로 IDLE을 시도할 때는 Help -> Python Documentation이 작동하는지 확인해야 합니다. 이런 방식으로 pydoc을 시도할 때는(“Module Docs” 시작 메뉴 항목), “Start Browser” 버튼이 작동하는지 확인하고, 임의의 모듈(예: “random” <윙크>)을 검색할 수 있는지, 그리고 “go to selected” 버튼이 작동하는지 확인하십시오.

여기서 얼마나 많은 것이 잘못될 수 있는지 놀라울 정도이며, 막바지에 체크인된 코드가 이러한 것들 중 하나를 얼마나 자주 망가뜨리는지는 더욱 놀랍습니다. 만약 여러분이 “Windows 전문가”라면, 여러분이 Windows에서 정기적으로 테스트하는 유일한 사람일 가능성이 높다는 점과 Windows가 그저 엉망이라는 점을 명심하십시오.

각 대상 아키텍처에 대해 테스트를 반복하십시오. 관리자 계정과 일반 사용자(파워 유저가 아닌) 계정 모두로 시도해 보십시오.