개발 주기¶
코어 팀 구성원의 책임은 개발자가 작업하는 Python 브랜치의 종류와 그 브랜치가 어느 단계에 있는지에 따라 달라집니다.
용어를 명확히 하자면, Python은 프로덕션용 릴리스에 major.minor.micro 명명법을 사용합니다. 따라서 Python 3.1.2 최종 릴리스의 경우 메이저 버전은 3, 마이너 버전은 1, 마이크로 버전은 2입니다.
새 메이저 버전은 예외적입니다. 호환성을 크게 깨뜨리는 변경이 꼭 필요하다고 판단될 때만 나오며, 아주 오래전부터 미리 계획됩니다.
새 마이너 버전은 기능 릴리스입니다. 현재 개발 중 브랜치에서 매년 릴리스됩니다.
새 마이크로 버전은 버그 수정 릴리스입니다. 대략 2개월마다 릴리스되며, 유지보수 브랜치에서 준비됩니다.
추가 한정어(Alpha, Beta, 릴리스 후보)가 붙는 최종이 아닌 버전도 배포합니다. 이러한 버전은 프로덕션 사용이 아니라 숙련된 사용자의 테스트를 목적으로 합니다.
Python의 각 릴리스는 소스 저장소에 vX.Y.ZTN 형식의 태그로 표시됩니다. 여기서 X는 메이저 버전, Y는 마이너 버전, Z는 마이크로 버전, T는 릴리스 수준(알파 릴리스는 a, 베타는 b, 릴리스 후보는 rc, 최종 릴리스는 null)이며, N은 릴리스 일련번호입니다. 릴리스 태그의 몇 가지 예는 v3.7.0a1, v3.6.3, v2.7.14rc1입니다.
브랜치¶
릴리스 여부와 관계없이 각 기능 버전마다 브랜치가 하나씩 있습니다(예: 3.12, 3.13).
개발 중(main) 브랜치¶
main 브랜치는 다음 기능 릴리스를 위한 브랜치입니다. 새 기능, 의미 변경, 성능 개선, 버그 수정 등 모든 종류의 변경이 활발하게 개발되고 있습니다.
릴리스 수명 주기의 어느 시점에, 한 기능 버전의 이후 마이크로 버전(3.12.1, 3.12.2 등)을 위한 모든 버그 수정 작업을 담당할 새 유지보수 브랜치가 생성됩니다.
베타에 진입하는 시점(3.14.0 베타 1)에 릴리스 유지 보수 브랜치(3.14)를 만듭니다. 이렇게 하면 3.n 릴리스의 베타 및 릴리스 후보 안정화 기간과 병행하여 main 브랜치에서 3.n+1 릴리스의 기능 개발을 진행할 수 있습니다.
유지 보수 브랜치¶
현재 버그 수정을 위해 유지보수되고 있는 이전 기능 릴리스의 브랜치이거나, 베타 또는 릴리스 후보 단계에 있는 다음 기능 릴리스의 브랜치입니다. 보통 어느 시점이든 유지 보수 브랜치는 한 개 또는 두 개 있습니다. 새 마이너 버전(3.x.0)의 최종 릴리스 이후 유지 보수 브랜치에서 만들어지는 릴리스는 버그 수정 릴리스 또는 유지 보수 릴리스라고 부르며, 두 용어는 같은 뜻으로 쓰입니다. 이러한 릴리스의 마이크로 버전 번호는 0보다 큽니다.
유지 보수 브랜치에 백포트되는 변경은 두 그룹으로 나뉩니다. 위험도가 낮은 변경(버그 수정, 테스트 개선, 문서 수정)은 별도 논의 없이 백포트할 수 있습니다. 위험도가 높은 변경(새 기능, 의미 변경, 성능 개선)은 회귀를 일으킬 수 있으므로 일상적으로 백포트하지 않습니다. 또한 유지 보수 브랜치의 일반 규칙으로, 같은 계열의 마이크로 릴리스(3.12.1, 3.12.2 등) 사이에서는 어느 시점에서도 호환성이 깨져서는 안 됩니다. 두 규칙 모두 드문 예외만 허용되며, 각 예외에는 사전 논의에서 합의된 타당한 근거가 필요합니다.
변경을 백포트하면 향후 충돌 위험이 줄어듭니다. 문서의 경우 대부분의 독자가 개발 문서 대신 안정 문서에 접근하기 때문에, 백포트하면 개선 사항이 더 잘 드러납니다.
새 유지 보수 브랜치는 보통 다음 기능 릴리스 주기가 기능 동결에 도달하는 시점, 즉 첫 번째 베타 사전 릴리스 시점에 만들어집니다. 그 시점부터 남은 사전 릴리스, 최종 릴리스(3.x.0), 이후의 버그 수정 릴리스를 위한 변경은 해당 유지 보수 브랜치에 병합됩니다.
최종 릴리스(3.x.0) 이후 어느 시점에 이전 마이너 버전의 유지 보수 브랜치는 보안 모드로 전환되며, 보통 릴리스 관리자의 재량에 따라 최소 한 번의 버그 수정 릴리스를 더 낸 뒤에 전환됩니다. 예를 들어 3.11 유지 보수 브랜치는 3.12.2 릴리스 뒤에 나온 3.11.9 버그 수정 릴리스 이후 보안 모드로 전환되었습니다.
보안 브랜치¶
생성된 지 5년이 지나지 않았지만 더 이상 버그 수정 모드가 아닌 브랜치를 보안 브랜치라고 합니다.
보안 브랜치에는 크래시, 권한 상승처럼 공격자가 악용할 수 있는 문제를 수정하는 변경만 반영하며, 선택적으로 서비스 거부 공격 같은 다른 문제의 수정도 반영할 수 있습니다. 그 밖의 변경은 보안 위험으로 간주되지 않으므로 보안 브랜치에 백포트하지 않습니다. 릴리스 전에 테스트를 성공적으로 실행할 수 있어야 하므로, 열려 있는 보안 브랜치에서 완전히 실패하는 테스트를 수정하는 것도 고려해야 합니다.
보안 브랜치에 커밋할 때는 Python 버전 상태에 나열된 해당 기능 버전의 릴리스 관리자와 조율해야 합니다. 보안 브랜치에 풀 리퀘스트를 병합하는 것은 릴리스 관리자만 할 수 있습니다. 보안 브랜치에서 나오는 모든 릴리스는 소스 전용이며, 실제 보안 수정이 브랜치에 적용되었을 때만 이루어집니다. 이러한 릴리스의 마이크로 버전 번호는 마지막 버그 수정 릴리스보다 큽니다.
수명 종료 브랜치¶
수명 종료 상태에 도달한 릴리스 주기의 코드 베이스는 동결되며, 저장소에 더 이상 브랜치가 존재하지 않습니다. 수명이 종료된 브랜치의 최종 상태는 이전 브랜치와 같은 이름의 태그로 기록됩니다(예: 3.8 또는 2.7).
Python 버전 상태 페이지에 활성 브랜치와 수명 종료 브랜치의 목록이 있습니다.
각 Python 버전의 최신 릴리스는 다운로드 페이지에서 찾을 수 있습니다.
단계¶
Python의 개발 중 버전이 어느 단계에 있느냐에 따라 VCS(버전 관리 시스템) 커밋과 관련된 코어 팀 구성원의 책임이 달라집니다.
프리알파¶
가장 최근의 최종 릴리스 이후 공식 릴리스가 한 번도 나오지 않았다면 브랜치는 이 단계에 있습니다. 커밋에 특별한 제한은 없지만, 일반적인 권장 사항(풀 리퀘스트 리뷰 받기, 빌드봇을 깨뜨리지 않기)은 그대로 적용됩니다.
알파¶
알파 릴리스는 보통 의미를 바꾸거나 Python에 무언가를 추가하는 변경을 반영하기 시작해야 한다는 점을 코어 팀에게 상기시키는 역할을 합니다. 이러한 변경은 Beta 기간에 추가해서는 안 되기 때문입니다. 그 외에는 알파 단계에서 새로 적용되는 제한이 없습니다.
베타¶
첫 번째 베타 릴리스가 공개된 후에는 새로운 기능을 받아들이지 않습니다. 이제는 버그 수정과 문서 및 테스트 개선만 커밋할 수 있습니다. 이 시기에 코어 팀은 알파 및 베타 릴리스를 내려받은 사용자가 보고한 회귀와 그 밖의 새로운 문제를 수정하는 데 집중해야 합니다.
베타 단계는 커밋 리뷰가 필요하다는 추가 부담만 없을 뿐, RC 단계와 거의 같다고 볼 수 있습니다.
릴리스 후보(RC)¶
RC 릴리스를 준비하는 브랜치에는 다른 코어 팀 구성원이 리뷰한 버그 수정만 적용할 수 있습니다. 일반적으로 이러한 문제는 최종 릴리스 전에 수정할 가치가 있을 만큼 심각해야 합니다(예: 크래시). 이 시점에서는 안정성이 가장 중요하므로, 그 밖의 모든 문제는 다음 개발 주기로 미뤄야 합니다.
목표는 RC와 최종 릴리스 사이에 코드 변경이 없도록 하는 것이지만, 최종 문서 수정이나 테스트 수정이 필요할 수 있습니다. 이러한 변경을 제안하려면 먼저 릴리스 관리자와 논의해야 합니다.
RC 기간에는 변경이 아무리 작더라도 동료 리뷰를 건너뛸 수 없습니다! 단순히 복사하여 붙여 넣는 변경이더라도 모든 변경에 코어 팀 구성원의 동료 리뷰가 필요합니다.
최종 릴리스¶
최종 릴리스를 만드는 동안에는 릴리스 관리자(RM)만 브랜치를 변경할 수 있습니다.
저장소 관리¶
소스 코드는 현재 Python 조직의 GitHub에 호스팅되어 있습니다.
조직 저장소 정책¶
GitHub Python 조직 안의 저장소는 Python 언어, CPython 참조 구현, 그 문서와 개발 워크플로와 관련된 것이어야 합니다. 예를 들어 다음과 같은 것이 포함됩니다:
Python의 참조 구현과 관련 저장소: CPython.
CPython 개발을 위한 도구와 지원: pyperformance, Bedevere.
Python/CPython 기능을 위한 헬퍼와 백포트: typing_extensions, typeshed, tzdata, pythoncapi-compat.
위의 모든 것에 대한 문서와 웹사이트: python.org 저장소, PEPs, Devguide, 문서 번역.
위의 모든 것을 위한 인프라: docsbuild-scripts, buildmaster-config.
공식 개발 관련 프로세스와 행사에 대한 논의와 기록: steering-council, core-sprint.
조직에 새 저장소를 추가하기 전에 Committers Discourse 카테고리에서 논의를 열어 합의를 구하십시오. 사람들이 이에 동의하면 Python 운영 위원회에 승인을 요청하십시오. PEP 545를 따르는 문서 번역에는 이 절차가 필요하지 않으며, 코어 팀 구성원의 재량으로 추가할 수 있다는 점에 유의하십시오.
여러 저장소가 역사적인 이유로 조직에 남아 있으며, 오늘날이라면 추가하기에 적절하지 않을 것이라는 점에 유의하십시오.
일반적으로 새 저장소는 개인 GitHub 계정이나 다른 GitHub 조직에서 시작해야 합니다. 저장소가 성숙해지면 조직으로 옮기는 것은 비교적 쉽습니다. 예를 들어 현재라면 asyncio, exceptiongroups 같은 실험적 기능과 새 가이드 및 기타 문서의 초안(예: redistributor-guide)이 이에 해당합니다.
범용 도구와 라이브러리(예: mypy 또는 Black)도 python 조직 밖에서 개발해야 합니다. 단, 코어 개발자들이 (SC를 대표로 하여) 특정 구현을 특별히 “공인”하고자 하는 경우(typeshed, tzdata, pythoncapi-compat처럼)는 예외입니다.
조직 소유자 정책¶
GitHub 조직 소유자(Organization Owner) 역할은 Python 조직의 모든 측면을 완전히 관리할 수 있게 합니다. 여기에는 조직 멤버십, 팀 멤버십, 접근 제어, 모든 저장소에 대한 병합 권한을 포함하여 모든 수준의 모든 측면을 조회하고 관리하는 것이 포함됩니다. 권한 수준에 대한 자세한 내용은 조직 권한 수준에 관한 GitHub 문서를 참조하십시오. 이 역할은 Python 언어, 커뮤니티, 인프라의 보안에 있어 가장 중요합니다.
Python Software Foundation의 전무 이사는 GitHub 조직 소유자 지위에 관한 권한을 Python Software Foundation 인프라 엔지니어인 Jacob Coffee에게 위임합니다. 이 역할을 부여하는 일반적인 사유는 인프라 직원 자격, Python Software Foundation 법률 고문이며, 그 밖의 경우에는 Python Software Foundation 직원에게 부여합니다.
활동하지 않거나 연락이 닿지 않는 구성원은 통지 여부와 관계없이 제외될 수 있습니다. 더 이상 이 수준의 접근 권한이 필요하지 않은 구성원은 통지 후 제외됩니다.
Python 조직의 소유자 지위를 유지하려면 사용자가 다중 인증(Multi-Factor Authentication)을 활성화해야 합니다.
현재 소유자¶
이름 |
역할 |
GitHub 사용자 이름 |
|---|---|---|
Benjamin Peterson |
인프라 직원 |
benjaminp |
Noah Kantrowitz |
인프라 직원 |
coderanger |
Donald Stufft |
인프라 직원 |
dstufft |
Ee Durbin |
인프라 직원 |
ewdurbin |
Jacob Coffee |
PSF 인프라 엔지니어 |
JacobCoffee |
Petr Viktorin |
CPython 상주 개발자 |
encukou |
Łukasz Langa |
ambv |
일부 작업(스팸 계정 차단, 새 사용자 초대, 조직 수준 설정 조정)은 GitHub의 Python 조직 소유자만 수행할 수 있습니다. 조직 소유자에게 도움을 요청하려면 @python/organization-owners 팀을 멘션하면 됩니다.
저장소 관리자 역할 정책¶
저장소의 관리자(Administrator) 역할은 협업자, 접근 제어, 통합, 웹훅, 브랜치 보호를 비롯한 모든 측면을 관리할 수 있게 합니다. 권한 수준에 관한 자세한 내용은 저장소 권한 수준에 관한 GitHub 문서를 참조하십시오. 이 역할이 부여되는 일반적인 사유는 핵심 워크플로 도구의 유지 관리, 모든 개발 중, 유지 보수, 보안 모드 릴리스의 릴리스 관리자, 그리고 중복성 확보를 위해 필요한 추가 Python 코어 팀 구성원입니다. 핵심 워크플로 프로젝트에 필요한 경우 가끔 임시 관리자 접근 권한을 부여하는 것은 허용됩니다.
활동하지 않거나 연락이 닿지 않는 구성원은 통지 여부와 관계없이 제외될 수 있습니다. 더 이상 이 수준의 접근 권한이 필요하지 않은 구성원은 통지 후 제외됩니다.
저장소의 관리자 지위를 유지하려면 사용자가 다중 인증(Multi-Factor Authentication)을 활성화해야 합니다.
현재 관리자¶
이름 |
역할 |
GitHub 사용자 이름 |
|---|---|---|
Savannah Ostrowski |
Python 3.16 및 3.17 릴리스 관리자 |
savannahostrowski |
Hugo van Kemenade |
Python 3.14 및 3.15 릴리스 관리자 |
hugovk |
Thomas Wouters |
Python 3.12 및 3.13 릴리스 관리자 |
Yhg1s |
Pablo Galindo |
Python 3.10 및 3.11 릴리스 관리자, buildbot.python.org 유지 관리자 |
pablogsal |
Łukasz Langa |
ambv |
|
Brett Cannon |
brettcannon |
|
Ezio Melotti |
bugs.python.org GitHub 웹훅 통합 유지 관리자 |
ezio-melotti |
Mariatta Wijaya |
bedevere, blurb_it, miss-islington 유지 관리자 |
Mariatta |
Seth Larson |
PSF 보안 상주 개발자 |
sethmlarson |
Petr Viktorin |
CPython 상주 개발자 |
encukou |
저장소 릴리스 관리자 역할 정책¶
개발 중, 유지 보수, 보안 모드 Python 릴리스의 릴리스 관리자에게는 저장소의 Administrator 권한이 부여됩니다. 릴리스 브랜치가 수명 종료 단계에 들어가면 해당 브랜치의 릴리스 관리자는 최종 태그를 만들고 브랜치를 삭제합니다. 그 후 해당 릴리스 관리자는 관리자 권한에서 제외됩니다.
브랜치의 릴리스 관리자로서 접근 권한을 유지하려면 사용자가 다중 인증(Multi-Factor Authentication)을 활성화해야 합니다.
PyPI 조직 정책¶
Python 코어 팀은 패키지를 게시하기 위해 PyPI의 cpython 및 python 조직을 소유하고 있습니다. 이 조직들에 패키지를 추가하면 얻는 주요 이점은 다음과 같습니다:
가시성: PyPI 조직 페이지에서 우리 패키지를 볼 수 있습니다
유지 보수성: 세분화된 PyPI 접근 권한을 공유하여 버스 팩터를 개선할 수 있습니다
어느 조직을 사용할지에 관한 일반 정책은 다음과 같습니다:
cpython: CPython 개발과 상당히 밀접하게 연관된 개발 도구를 위한 조직입니다. 예를 들어 blurb과 cherry-picker가 있습니다. 사용자는 CPython 자체를 개발하는 경우가 아니라면 일반적으로 신경 쓸 필요가 없습니다(그렇다고 해서 이 도구들을 다른 사람이 반드시 사용할 수 없어야 한다는 뜻은 아닙니다).
python: Python 코어 팀이 유지 관리하는 일반 사용자 대상 프로젝트를 위한 조직입니다. 예를 들어 pyperformance, python-docs-theme, tzdata가 있습니다.
거버넌스¶
Python 운영 위원회는 Python에 대한 전반적인 권한을 가지며, 그 책임 중 일부를 다른 그룹에 위임했습니다.
이 표에는 각 그룹의 책임을 정의하는 PEP와, 결정을 요청하기 위해 이슈를 열 수 있는 저장소가 나열되어 있습니다.
이름 |
PEP |
연락 저장소 |
|---|---|---|
운영 위원회 |
||
C API 워킹 그룹 |
||
문서 편집 위원회 |
||
타이핑 위원회 |
더 보기
모든 거버넌스 PEP: https://peps.python.org/topic/governance/