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

Python 개선 제안 한국어 번역

PEP 101 – Python 릴리스 입문 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 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

Python 릴리스를 만드는 일은 짜릿하고도 정신없는 과정입니다. “고양이 떼 몰기(herding cats)”라는 표현을 들어 보셨습니까? 가르랑거리는 그 작은 녀석들에게 안장까지 얹어 타고 시내로 나가는데, 그 친구들 몇 마리는 갓 간 발톱을 박은 채 여러분의 맨등에 단단히 매달려 있다고 상상해 보십시오. 그래도 귀엽기는 하다고 스스로를 달래 봅니다.

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

필요한 것들

릴리스 관리자로서 접근해야 할 리소스가 많습니다. 빠짐없이 정리했기를 바라는 목록은 다음과 같습니다.

  • 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으로 설치할 수 있습니다.
  • 파일을 업로드할 서버에 대한 접근 권한:
    • 다운로드 파일을 호스팅하는 서버인 downloads.nyc1.psf.io, 그리고
    • 문서를 호스팅하는 서버인 docs.nyc1.psf.io.
  • python/cpython에 대한 관리자 권한과 릴리스 관리자 팀 멤버십.
  • “API 키”를 포함한 www.python.org의 관리자 계정.
  • python/peps 저장소에 대한 쓰기 권한.

    이 글을 읽고 계신다면 아마 이미 이 권한을 가지고 계실 것입니다–모든 릴리스 관리자의 첫 번째 업무는 릴리스 일정 초안을 작성하는 것이기 때문입니다. 하지만 방금 자원하신 거라면… 걸려드셨습니다! 아니, 그러니까, 축하드립니다!

  • python-cabal이라고 불릴 수도 있고 아닐 수도 있는 극비 릴리스 관리자 메일링 리스트 구독. 이 건은 Barry를 ‘버그’처럼 귀찮게 졸라서 요청하십시오.
  • 릴리스에 서명할 때 사용할 @python.org 이메일 주소. postmaster@에 주소를 요청하십시오. 정식 계정을 받을 수도 있고, 리디렉션 별칭과 SMTP 자격 증명을 함께 받아 이 주소로 이메일을 보낼 수도 있습니다. 이렇게 보낸 이메일은 주요 이메일 제공업체에서 정상적인 메일로 인식됩니다.
  • Python 보안 대응팀에 추가되어야 합니다.

릴리스의 종류

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

  • 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

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

이어지는 설명에서 릴리스 유형별 단계에는 그에 맞게 표시가 붙어 있으며, 현재는 새 브랜치와 최종이 있습니다.

릴리스를 만드는 방법

다음은 Python 릴리스를 만들기 위해 거치는 단계입니다. 자동화할 수 있는 부분이 거의 없기 때문에 일부 단계는 다른 단계보다 더 모호합니다(예: NEWS 항목 작성). 보통 전문가가 수행하는 단계에는 해당 전문가의 역할을 적어 두었습니다. 그 밖의 단계는 릴리스를 수행하도록 지정된 사람인 릴리스 관리자(RM)가 수행한다고 간주하십시오. 역할과 현재 담당 전문가는 다음과 같습니다:

Note

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

모든 전문가가 각자 맡은 부분을 갱신하기 전에는 (웹사이트를 갱신하고 공지를 보내는 방식으로) 릴리스를 공개해서는 안 됩니다. 드물게 Windows나 Mac 담당 전문가와 연락이 닿지 않는 경우에는 “(플랫폼) 바이너리는 곧 제공될 예정입니다”라는 메시지를 추가하고 진행해도 됩니다.

아래 예제에서는 다음 규칙을 사용합니다. 릴리스 번호는 3.X.YaN 형식으로 표기합니다. 예를 들어 Python 3.13.0 알파 3은 3.13.0a3이며, “a”는 알파, “b”는 베타, “rc”는 릴리스 후보를 뜻합니다.

릴리스 태그의 이름은 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 Developer’s Guide에서 권장하는 표준 설정을 사용하면, 여러분의 포크는 origin으로, 표준 CPython 저장소는 upstream으로 불립니다. 포크의 브랜치에서 릴리스 태그 지정을 포함한 릴리스 엔지니어링 작업을 수행하며, 바이너리를 만드는 다른 전문가들과도 이 브랜치를 공유합니다.

    최종 또는 릴리스 후보 2 이상 릴리스에서 마지막 rc 이후 병합된 변경 사항 중 일부만 골라 다음 rc나 최종 릴리스에 체리픽하려는 경우, 가장 최근의 릴리스 후보 태그(예: v3.8.0rc1)에서 시작하는 릴리스 엔지니어링 브랜치를 만들어야 합니다. 그런 다음 필요한 변경 사항을 표준 릴리스 브랜치에서 릴리스 엔지니어링 브랜치로 체리픽하고 평소처럼 진행하십시오. 이전 rc 이후의 변경 사항을 모두 포함하려는 경우에는 평소처럼 진행하면 됩니다.

  • 릴리스 클론의 현재 브랜치가 릴리스하려는 브랜치인지 확인하십시오(git status).
  • 버전 번호를 지정하여 blurb release <version>을 실행하십시오(예: blurb release 3.4.7rc1). 이 명령은 최근의 모든 뉴스 blurb를 이번 릴리스의 버전 번호가 표시된 하나의 파일로 병합합니다.
  • 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가 편집해야 하는 파일들을 편집기 창(windows)으로 띄워 줍니다.

    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

    이 단계는 git tag 명령을 -s 옵션과 함께 실행하여, 저장소의 릴리스 태그를 여러분의 GPG 키로 서명합니다. 키를 선택하라는 메시지가 나오면 릴리스 tarball 등에 서명할 때 사용하는 개인 키를 선택하십시오.

  • 보안 전용 모드 시작 릴리스와 지원 종료 릴리스의 경우 두 파일을 검토하고, 모든 활성 브랜치에서 버전을 그에 맞게 갱신하십시오.
  • 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 tarball과 xz tarball을 만듭니다.
    • 문서 tar 파일과 zip 파일을 만듭니다.
    • 소스 tarball을 검사하여, 완전히 깨끗한 초기 상태에서 빌드한 결과가 회귀 테스트를 통과하는지 확인합니다.
    • 전문가가 필요하지 않은 플랫폼용 바이너리를 빌드하고 테스트합니다.

    생성된 아티팩트는 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 Store용 패키지를 만듭니다.
    • 설치 프로그램에 대한 기본 검증을 수행합니다.
    • 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 등과 함께 scp나 rsync로 downloads.nyc1.psf.io의 홈 디렉터리에 복사하십시오.

    파일 업로드가 끝나기를 기다리는 동안 나머지 작업을 계속 진행할 수 있습니다. 또한 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 그룹에 속하고 그룹 쓰기 권한이 있는지 확인하십시오.
    • 문서와 다운로드 모두 캐싱 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에게서 승인을 받았습니까?
  • ME에게서 승인을 받았습니까?

승인을 받았다면 이제 릴리스 엔지니어링 브랜치를 메인 저장소에 다시 병합할 차례입니다.

  • 변경 사항을 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
  • 최종 릴리스나 릴리스 후보 2 이상 릴리스라면 병합 후 정리 작업이 필요할 수 있습니다. 최상위 README.rst와 include/patchlevel.h 파일을 확인하여, 계속 진행되는 개발에 맞는 릴리스 후 값이 이제 반영되어 있는지 확인하십시오. 패치 레벨은 릴리스 태그에 +dev를 붙인 값이어야 합니다. 또한 이번 릴리스를 위해 표준 릴리스 브랜치의 변경 사항을 릴리스 엔지니어링 브랜치로 체리픽했다면, 작업 중인 릴리스로 체리픽된 각 blurb 항목을 이제 Misc/NEWS.d/next 디렉터리에서 수동으로 제거해야 합니다. 해당 blurb 항목은 이제 새 릴리스를 위해 병합된 x.y.z.rst 파일에 포함되어 있기 때문입니다. 그렇지 않으면 blurb 항목이 changelog.html 파일에 두 번, 즉 Python next 아래에 한 번, x.y.z 아래에 또 한 번 나타납니다.
  • 이 변경 사항을 검토하고 커밋하십시오:
    git commit -m 'Post release updates'
  • 새 브랜치 릴리스(예: 첫 번째 베타)라면, 다음 기능 릴리스의 개발을 시작할 수 있도록 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를 한 번 더 실행하십시오.

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

  • 커밋하고 메인 저장소에 푸시하십시오:
    # 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” 아래에 분류되어 있습니다.

    가장 쉬운 방법은 아마도 기존 Python 릴리스 “page”에서 필드를 복사한 뒤 필요에 따라 수정하는 것입니다.

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

다음 단계는 무엇입니까?

  • 검증하십시오! 사용자가 된 것처럼 www.python.org에서 파일을 내려받아 Python을 빌드해 보십시오. 이 단계는 간과하기 너무 쉬우며, 실제로 여러 차례 쓸모없는 릴리스 파일이 나온 적이 있습니다. 한 번은 전반적인 서버 문제로 모든 파일이 알 수 없는 이유로 손상되었고, 한 번은 소스 tarball이 잘못 빌드되었으며, SF의 파일 업로드 과정에서 파일이 잘린 적도 한 번이 아니었습니다. 그 밖에도 여러 일이 있었습니다.
  • 기뻐하십시오. 한잔하십시오. 즐기십시오. 이와 같은 PEP를 작성하십시오. 아니면 Guido처럼 휴가를 떠나십시오.

방금 Python 릴리스를 만들었습니다!

지원 종료로 전환하기

현재 정책에 따르면 릴리스 브랜치는 일반적으로 최초 릴리스 후 5년이 지나면 지원 종료 상태가 됩니다. 이 정책은 Python 개발자 가이드에서 더 자세히 다룹니다. 지원 종료 시점이 되면 릴리스 관리자인 여러분이 직접 수행하거나 다른 사람이 수행하도록 챙겨야 하는 여러 작업이 있습니다. 그 작업 중 일부는 다음과 같습니다:

  • 아직 릴리스되지 않은 나머지 변경 사항을 배포하기 위해 선택적으로 최종 릴리스를 만듭니다.
  • 릴리스 브랜치의 현재 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)로 설정하십시오.
  • 개발자 가이드에서 해당 브랜치에 대한 참조를 갱신하거나 제거하십시오.
  • issue tracker에서 해당 릴리스를 퇴역시키십시오. 작업은 다음과 같습니다:
    • 이 버전의 이슈를 다음 지원 버전으로 갱신합니다
    • 버전 목록에서 버전 레이블을 제거합니다
    • 퇴역한 버전에 대한 needs backport to 레이블을 제거합니다
    • 이 브랜치로 표시된 열린 이슈를 검토하고 처리합니다
  • 지원 종료 배너를 추가하기 위해 온라인 문서의 최종 빌드를 실행하십시오
  • 평소에 공지하던 곳에 브랜치 퇴역을 알리십시오:
  • 은퇴를 즐기시고, 훌륭하게 해낸 일의 성취감을 만끽하십시오!

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” <wink>)이나 검색할 수 있는지, 그다음 “go to selected” 버튼이 작동하는지 확인하십시오.

여기서 잘못될 수 있는 것이 얼마나 많은지 놀라울 정도이며, 마지막 순간의 체크인이 이 중 하나를 망가뜨리는 일이 얼마나 잦은지는 더욱 놀랍습니다. 여러분이 “Windows 전문가”라면, Windows에서 정기적으로 테스트하는 사람은 아마 여러분뿐일 것이며 Windows는 그야말로 엉망이라는 점을 명심하십시오.

대상 아키텍처마다 테스트를 반복하십시오. Admin 계정과 일반 User 계정(Power User 계정이 아님)으로 모두 시험해 보십시오.