개발 주기¶
코어 팀 구성원의 책임은 개발자가 작업하는 Python 브랜치의 종류와 해당 브랜치의 단계에 따라 달라집니다.
용어를 명확히 하자면, Python은 프로덕션 준비가 완료된 릴리스에 major.minor.micro 명명법을 사용합니다. 따라서 Python 3.1.2 최종 릴리스에서 메이저 버전은 3, 마이너 버전은 1, 마이크로 버전은 2입니다.
새 메이저 버전은 예외적입니다. 호환성이 크게 깨지는 변경이 필요하다고 판단될 때만 나오며, 매우 오래전부터 계획됩니다.
새 마이너 버전은 기능 릴리스입니다. 현재 개발 중 브랜치에서 매년 릴리스됩니다.
새 마이크로 버전은 버그 수정 릴리스입니다. 약 2개월마다 릴리스되며, 유지 관리 브랜치에서 준비됩니다.
또한 알파, 베타, 릴리스 후보 같은 한정자가 추가된 비최종 버전도 배포합니다. 이러한 버전은 프로덕션 용도가 아니라 고급 사용자의 테스트를 목적으로 합니다.
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년 미만이지만 더 이상 버그 수정 모드가 아닌 브랜치는 보안 브랜치입니다.
보안 브랜치에는 충돌, 권한 상승 등 공격자가 악용할 수 있는 문제와 선택적으로 서비스 거부 공격 같은 기타 문제를 수정하는 변경 사항만 적용합니다. 그 밖의 변경 사항은 보안 위험으로 간주되지 않으므로 보안 브랜치에 백포트하지 않습니다. 릴리스 전에 테스트를 성공적으로 실행할 수 있어야 하므로, 열려 있는 보안 브랜치에서 완전히 실패하는 테스트를 수정하는 것도 고려해야 합니다.
보안 브랜치에 대한 커밋은 파이썬 버전 상태에 나열된 해당 기능 버전의 릴리스 관리자와 조율해야 합니다. 보안 브랜치에 대한 풀 리퀘스트 병합은 릴리스 관리자만 수행할 수 있습니다. 보안 브랜치에서 이루어지는 모든 릴리스는 소스 전용이며, 실제 보안 수정 사항이 브랜치에 적용된 경우에만 진행합니다. 이러한 릴리스의 마이크로 버전 번호는 마지막 버그 수정 릴리스보다 큽니다.
수명 종료 브랜치¶
수명 종료 상태에 도달한 릴리스 주기의 코드베이스는 동결되며 저장소에 더 이상 브랜치가 존재하지 않습니다. 수명이 종료된 브랜치의 최종 상태는 이전 브랜치와 동일한 이름의 태그로 기록됩니다. 예를 들면 3.8 또는 2.7입니다.
관련 파이썬 버전 상태 페이지에는 활성 브랜치와 수명 종료 브랜치의 목록이 있습니다.
각 Python 버전의 최신 릴리스는 다운로드 페이지에서 확인할 수 있습니다.
단계¶
Python의 개발 중 버전이 어느 단계에 있는지에 따라 VCS(버전 관리 시스템) 커밋과 관련된 코어 팀 구성원의 책임이 달라집니다.
프리 알파¶
최신 최종 릴리스 이후 공식 릴리스가 이루어지지 않은 경우 브랜치는 이 단계에 있습니다. 커밋에 특별한 제한은 없지만, 일반적인 권고 사항은 적용됩니다(풀 리퀘스트 검토받기, 빌드봇 중단 방지하기).
알파¶
알파 릴리스는 일반적으로 의미 체계를 변경하거나 Python에 무언가를 추가하는 변경 사항을 반영하기 시작해야 한다는 점을 코어 팀에 상기시키는 역할을 합니다. 이러한 사항은 Beta 중에 추가해서는 안 되기 때문입니다. 그 외에는 알파 단계에서 새로운 제한이 적용되지 않습니다.
베타¶
첫 번째 베타 릴리스가 공개된 후에는 새로운 기능을 수용하지 않습니다. 이제 버그 수정과 문서 및 테스트 개선 사항만 커밋할 수 있습니다. 이 시기에는 코어 팀이 알파 및 베타 릴리스를 다운로드한 사용자가 제출한 회귀와 기타 새로운 문제를 수정하는 데 집중해야 합니다.
베타 단계는 커밋 검토에 필요한 추가 부담이 없다는 점을 제외하면 RC와 매우 비슷하다고 볼 수 있습니다.
릴리스 후보(RC)¶
RC 릴리스를 준비하는 브랜치에는 다른 코어 팀 구성원이 검토한 버그 수정만 적용할 수 있습니다. 일반적으로 이러한 문제는 최종 릴리스 전에 수정할 가치가 있을 만큼 심각해야 합니다(예: 충돌). 이 시점에서는 안정성이 가장 중요한 고려 사항이므로 그 밖의 모든 문제는 다음 개발 주기로 미뤄야 합니다.
RC와 최종 릴리스 사이에 코드 변경이 없도록 하는 것이 목표이지만, 최종 문서나 테스트를 수정해야 할 수도 있습니다. 이러한 변경 제안은 먼저 릴리스 관리자와 논의해야 합니다.
변경 사항이 아무리 작더라도 RC 중에는 동료 검토를 생략할 수 없습니다! 단순한 복사하여 붙여넣기 변경이라도 모든 변경 사항은 코어 팀 구성원의 동료 검토를 받아야 합니다.
최종 릴리스¶
최종 릴리스를 제작할 때는 릴리스 관리자(RM)만 브랜치를 변경할 수 있습니다.
저장소 관리¶
소스 코드는 현재 Python organization 내의 GitHub에 호스팅되어 있습니다.
조직 저장소 정책¶
GitHub Python organization 내의 저장소는 Python 언어, CPython 참조 구현, 관련 문서 및 개발 워크플로와 관련되어야 합니다. 예를 들면 다음과 같습니다:
Python 참조 구현 및 관련 저장소: CPython.
CPython 개발을 위한 도구 및 지원: pyperformance, Bedevere.
Python/CPython 기능을 위한 도우미 및 백포트: typing_extensions, typeshed, tzdata, pythoncapi-compat.
조직 관련 저장소: Code of Conduct, .github.
위의 모든 항목에 관한 문서 및 웹사이트: python.org repository, PEPs, Devguide, 문서 번역.
위의 모든 항목을 위한 인프라: docsbuild-scripts, buildmaster-config.
공식 개발 관련 절차 및 행사에 관한 논의와 기록: steering-council, core-sprint.
조직에 새 저장소를 추가하기 전에 Committers Discourse category에서 합의를 구하는 논의를 시작하십시오. 사람들이 이에 동의하면 Python steering council에 권한을 요청하십시오. 코어 팀 구성원의 재량에 따라 추가할 수 있는 PEP 545를 따르는 docs translations에는 이 절차가 필요하지 않다는 점에 유의하십시오.
여러 저장소가 역사적인 이유로 조직에 남아 있으며, 오늘날에는 추가하기에 적절하지 않을 가능성이 높다는 점에 유의하십시오.
일반적으로 새 저장소는 개인 GitHub 계정이나 다른 GitHub 조직에서 시작해야 합니다. 저장소가 성숙하면 조직으로 옮기는 것은 비교적 쉽습니다. 예를 들어 현재는 asyncio, exceptiongroups 같은 실험적 기능과 새로운 지침 및 기타 문서의 초안(예: redistributor-guide)에 이 원칙이 적용됩니다.
범용 도구와 라이브러리(예: mypy 또는 Black)도 코어 개발자들(SC가 대표함)이 특정 구현을 명시적으로 “공인”하려는 경우(typeshed, tzdata, pythoncapi-compat 등)를 제외하고는 python 조직 외부에서 개발해야 합니다.
조직 소유자 정책¶
GitHub 조직 소유자 역할을 맡으면 Python 조직의 모든 측면을 완전히 관리할 수 있습니다. 여기에는 조직 구성원 자격, 팀 구성원 자격, 접근 제어, 모든 저장소의 병합 권한을 비롯하여 모든 수준의 모든 측면을 확인하고 관리하는 권한이 포함됩니다. 권한 수준에 관한 자세한 내용은 GitHub’s documentation on Organization permission levels을 참조하십시오. 이 역할은 Python 언어, 커뮤니티 및 인프라의 보안에 매우 중요합니다.
Python 소프트웨어 재단의 전무 이사는 GitHub 조직 소유자 지위에 관한 권한을 Python 소프트웨어 재단 인프라 엔지니어인 Jacob Coffee에게 위임합니다. 이 역할을 부여하는 일반적인 사유는 인프라 직원 자격, Python 소프트웨어 재단 법률 고문, 그리고 예비 인력으로서의 Python 소프트웨어 재단 직원입니다.
비활성 상태이거나 연락할 수 없는 구성원은 통지 여부와 관계없이 제외될 수 있습니다. 이 수준의 접근 권한이 더 이상 필요하지 않은 구성원은 통지 후 제외됩니다.
Python 조직의 소유자 지위를 유지하려면 사용자가 다단계 인증을 활성화해야 합니다.
현재 소유자¶
이름 |
역할 |
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 팀을 멘션할 수 있습니다.
저장소 관리자 역할 정책¶
저장소의 관리자 역할을 사용하면 공동 작업자, 접근 제어, 통합, 웹훅, 브랜치 보호를 비롯한 모든 측면을 관리할 수 있습니다. 권한 수준에 관한 자세한 내용은 저장소 권한 수준에 관한 GitHub 문서를 참조하십시오. 이 역할을 부여하는 일반적인 사유는 핵심 워크플로 도구 유지관리, 모든 개발 중, 유지관리, 보안 모드 릴리스의 릴리스 관리자, 그리고 필요한 경우 중복성 확보를 위한 추가 Python 코어 팀 구성원입니다. 핵심 워크플로 프로젝트에 필요한 경우 일시적인 관리자 접근 권한을 간헐적으로 부여하는 것은 허용됩니다.
비활성 상태이거나 연락할 수 없는 구성원은 통지 여부와 관계없이 제외될 수 있습니다. 이 수준의 접근 권한이 더 이상 필요하지 않은 구성원은 통지 후 제외됩니다.
저장소의 관리자 지위를 유지하려면 사용자가 다단계 인증을 활성화해야 합니다.
현재 관리자¶
이름 |
역할 |
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 릴리스의 릴리스 관리자에게는 저장소의 관리자 권한이 부여됩니다. 릴리스 브랜치가 수명 종료 단계에 들어가면 해당 브랜치의 릴리스 관리자는 최종 태그를 생성하고 브랜치를 삭제합니다. 이후 관리자에서 제외됩니다.
해당 브랜치의 릴리스 관리자 접근 권한을 유지하려면 사용자가 다단계 인증을 활성화해야 합니다.
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/