PEP 2026 – Python의 달력 버전 관리

Author:

Hugo van Kemenade

Discussions-To:

Discourse thread

Status:

Rejected

Type:

Process

Created:

11-Jun-2024

Python-Version:

3.26

Post-History:

14-Jun-2024

Resolution:

Discourse message

---

Table of Contents

• 초록
• 동기와 근거
  • 현재 체계
  • Python은 SemVer보다 오래되었습니다
  • 달력 기반 버전 관리
  • 연례 릴리스 주기
  • Python을 위한 CalVer
  • 더 이상 사용되지 않는 기능 제거 시점의 명확성
  • 지원 수명 주기의 명확성
  • 설치 시점의 명확성
  • 버전 지원의 명확성
  • 목표에 포함되지 않는 사항
• 사양
• 보안 관련 영향
• 이 내용을 가르치는 방법
• 기각된 아이디어
  • YY.0
    • 플랫폼 호환성 태그
    • 생태계 변경
    • python3 명령
    • CPython 변경 사항
    • YY.0 기각
  • YY.MM
  • 3.YYYY
    • PY_VERSION_HEX
  • 에디션
  • SemVer를 채택하고 4를 건너뛰기
  • 3.14 주기 중 변경
• 하위 호환성
  • 버전 매핑
• 전방 호환성
  • 향후 릴리스 주기 변경
    • 더 드문 릴리스
    • 더 잦은 릴리스
  • CalVer 폐지
• 각주
• 감사의 말
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 달력 연도를 포함하도록 Python의 버전 관리 체계를 업데이트할 것을 제안합니다.

달력 버전 관리(CalVer)는 버전을 세고 언제 출시될지(또는 출시되었는지) 찾아보는 것보다 모든 것을 달력 시간으로 변환하기 쉽게 합니다:

• 지원 수명 주기가 명확하므로 버전이 처음 출시된 시점을 쉽게 확인할 수 있습니다.
• 유지 관리자와 사용자가 지원 중단을 더 쉽게 관리할 수 있습니다.
• 버전이 수명 종료(EOL)에 도달할 시점을 더 쉽게 계산할 수 있습니다.
• 특히 새로운 학습자가 자신의 설치본이 얼마나 오래되었는지 이해하는 데 도움이 됩니다.
• 라이브러리와 애플리케이션에서 어떤 Python 버전을 지원할지 더 쉽게 판단할 수 있습니다.

Python 3.15가 되었을 버전부터 버전은 3.YY.micro가 되며, 여기서 YY는 최초 출시 연도입니다:

• Python 3.15 대신 Python 3.26이 2026년에 출시됩니다. EOL은 최초 출시 후 5년이므로, Python 3.26은 2031년에 EOL에 도달합니다.
• Python 3.27은 2027년에 출시되며, 이후에도 같은 방식으로 이어집니다.

동기와 근거

2019년에 PEP 602를 통해 연간 출시 주기를 채택했으며, 이를 통해 달력 버전 관리의 길이 열렸습니다:

연간 출시 일정을 채택하면 달력 버전 관리로 자연스럽게 전환할 수 있습니다. 예를 들어 Python 3.9가 20년 10월에 출시되므로 이를 “Python 3.20”이라고 부르는 식이며, 이후에도 같은 방식으로 적용됩니다(“Python 3.23”은 23년 10월에 출시되는 버전이 됩니다).

달력 버전 관리로 쉽게 전환할 수 있다는 점은 연간 출시 주기의 장점으로 볼 수 있지만, 이 PEP는 Python의 버전 관리 방식을 변경하는 것에 찬성하거나 반대하지 않습니다. 연간 출시 주기를 채택하게 된다면 버전 관리 문제는 별도의 PEP에서 다루게 됩니다.

이 PEP가 바로 그 PEP입니다.

현재 체계

일반 Python FAQ에서 확인할 수 있습니다: How does the Python version numbering scheme work?

Python 버전은 “A.B.C” 또는 “A.B”로 번호가 매겨집니다:

• A는 주 버전 번호입니다 – 언어에 실제로 큰 변경이 있을 때만 증가합니다.
• B는 부 버전 번호입니다 – 훨씬 덜 중대한 변경이 있을 때 증가합니다.
• C는 마이크로 버전 번호입니다 – 각 버그 수정 릴리스마다 증가합니다.

Python은 SemVer보다 오래되었습니다

Semantic Versioning (SemVer)은 출시의 의도를 전달하고자 하는 인기 있는 체계입니다(다만 항상 성공하는 것은 아닙니다).

MAJOR.MINOR.PATCH 형식의 버전 번호가 주어졌을 때 다음을 증가시킵니다:

1. 호환되지 않는 API를 변경할 때 MAJOR 버전
2. 하위 호환성 있는 방식으로 기능을 추가할 때 MINOR 버전
3. 하위 호환성 있는 버그 수정을 할 때 PATCH 버전

사람들은 Python이 SemVer를 따른다고 흔히 가정하며, complain about breaking changes in feature releases한다고 생각합니다. 그러나 Python은 SemVer보다 적어도 15년 앞섰습니다. SemVer 사양은 introduced in 2009되었고, Python 고유의 버전 관리 체계는 1.0 릴리스를 위해 added to source control in 1994되었습니다.

Python이 SemVer를 채택한다면, 더 이상 사용되지 않는 기능을 제거할 때마다 매년 새로운 메이저 버전이 올라가야 한다는 의미가 됩니다.

그러나 SemVer 대신 일부 프로젝트에서는 달력에 기반한 다른 버전 관리 체계를 채택했습니다.

달력 기반 버전 관리

Calendar Versioning (CalVer)을 사용하면 버전 번호에 날짜의 일부 요소를 포함시킵니다. 예를 들어, Ubuntu와 Black은 연도와 월을 사용합니다 — Ubuntu 24.04는 2024년 4월에 출시되었으며, pip와 PyCharm은 연도만 사용합니다.

Ubuntu	Black	pip	PyCharm
YY.0M.micro	YY.MM.micro	YY.minor.micro	YYYY.minor.micro
23.04 | 23.10 | 24.04 | 24.10	23.12.1 | 24.1.0 | 24.1.1 | 24.2.0	23.3 | 23.3.1 | 23.3.2 | 24.0	2023.3.5 | 2024.1 | 2024.1.1 | 2024.1.2

다음은 모두 어떤 형태로든 연도를 사용하는 프로그래밍 언어 표준들입니다:

Ada	Algol	C	C++	Fortran	ECMAScript | 일명 JavaScript
YY / YYYY	YY	YY	YY	YY / YYYY	YYYY
83 | 95 | 2012 | 2022	58 | 60 | 68	89 | 99 | 11 | 23	98 | 03 | 11 | 23	66 | 90 | 2003 | 2023	2020 | 2021 | 2022 | 2023

연례 릴리스 주기

2019년부터 매년 릴리스를 하나씩 만들었습니다.

• 3.15.0은 2026년에 릴리스됩니다.
• 3.16.0은 2027년에 릴리스됩니다.
• 3.17.0은 2028년에 릴리스됩니다.
• 3.18.0은 2029년에 릴리스됩니다.
• 3.19.0은 2030년에 릴리스됩니다.

이는 어느 정도 달력 기반이지만, 11년만큼 오프셋되어 있습니다.

Python을 위한 CalVer

가장 간단한 CalVer 선택지는 메이저 버전 3을 유지하고 마이너 버전에 연도를 인코딩하는 것입니다.

• 3.26.0은 2026년에 릴리스됩니다.
• 3.27.0은 2027년에 릴리스됩니다.
• 3.28.0은 2028년에 릴리스됩니다.
• 3.29.0은 2029년에 릴리스됩니다.
• 3.30.0은 2030년에 릴리스됩니다.

예를 들어 3.26은 2026년에 릴리스됩니다. 이를 통해 릴리스가 처음 출시된 시점을 쉽게 알 수 있습니다.

더 이상 사용되지 않는 기능 제거 시점의 명확성

더 이상 사용되지 않는 기능에 대한 경고에는 해당 기능이 제거될 버전이 자주 언급됩니다. 예를 들면 다음과 같습니다.

DeprecationWarning: ‘ctypes.SetPointerType’ is deprecated and slated for removal in Python 3.15

그러나 CalVer를 알고 있다면, 경고를 통해 조치를 취할 수 있는 기간이 얼마나 남았는지 즉시 알 수 있습니다.

DeprecationWarning: ‘ctypes.SetPointerType’ is deprecated and slated for removal in Python 3.26

지원 수명 주기의 명확성

현재는 릴리스가 수명 종료되는 시점을 알아내기가 조금 어렵습니다. 먼저 최초 릴리스 시점을 찾아본 다음 5년을 더해야 합니다:

“Python 3.11은 언제 EOL이 됩니까?”

“음, 어디 보자… PEP 664는 3.11 릴리스 일정이며, 3.11이 2022년에 릴리스되었고 5년 후에 EOL이 된다고 합니다. 따라서 2022 + 5 = 2027입니다.”

그러나 최초 릴리스 연도가 버전에 바로 표시되어 있다면 훨씬 쉽습니다:

“Python 3.26은 언제 EOL이 됩니까?”

“26 + 5 = [20]31”

설치 시점의 명확성

버전에 연도가 포함되어 있으면 설치한 지 얼마나 되었는지 알아내기가 더 쉽습니다. 예를 들어 현재 체계에서는 2035년에 Python 3.15를 사용하고 있다면, 이것이 2026년에 처음 릴리스되었고 2031년부터 EOL 상태라는 점이 즉시 명확하지 않습니다.

CalVer를 알고 있다면 2035년에 Python 3.26을 사용할 때, 9년 전에 처음 릴리스되었으므로 업그레이드할 때가 되었을 가능성이 높다는 점이 명확합니다.

이를 통해 사람들이 보안 지원을 여전히 받고 있는 지원 대상 릴리스로 전환하도록 유도하고, 오래된 설치를 사용하고 있을 수 있는 신규 사용자 교육에도 도움을 줄 수 있습니다.

버전 지원의 명확성

CalVer를 사용하면 어떤 Python 버전을 지원할지 판단하기가 더 쉬워집니다.

예를 들어 CalVer가 없다면 2031년에 최소 호환 Python 버전을 3.19로 설정하는 것은 버전 채택과 지원에 관해 공격적인 가정을 하는 것입니다.

그러나 CalVer를 사용하면 최소 버전을 3.30으로 설정하는 경우에는 더 분명해집니다. 2031. 더 폭넓은 지원을 위해서는 3.26으로 설정하는 것을 선호할 수도 있습니다.

마찬가지로 모든 CPython 업스트림 버전을 지원하는 라이브러리 유지 관리자는 5개 버전(프리릴리스를 포함하면 6개)에 대해 테스트해야 합니다.

예를 들어 2030년에 CalVer가 없다면 지원 대상 버전은 다음과 같습니다:

• 3.15, 3.16, 3.17, 3.18, 3.19

CalVer를 사용하면 다음과 같습니다:

• 3.26, 3.27, 3.28, 3.29, 3.30

유지 관리자는 어떤 버전이 현재 버전이며 테스트가 필요한지 한눈에 볼 수 있습니다.

목표에 포함되지 않는 사항

현재 체계와 마찬가지로 버그 수정 및 보안 릴리스에서는 마이크로 버전만 증가하며, 메이저 및 마이너 버전은 변경하지 않습니다. 예를 들면:

	현재 방식	제안된 3.YY.micro
최초 릴리스 (2026년 10월)	3.15.0	3.26.0
첫 번째 버그 수정 릴리스 (2026년 12월)	3.15.1	3.26.1
두 번째 버그 수정 릴리스 (2027년 2월)	3.15.2	3.26.2
…	…	…
마지막 보안 릴리스 (2031년 10월)	3.15.17	3.26.17

관련 PEP 602(Python의 연례 릴리스 주기)에 대한 변경 없음:

• 기능 버전을 개발하는 17개월 기간(알파, 베타 및 릴리스 후보)도 변경하지 않습니다.
• 지원 기간도 변경하지 않습니다: 전체 지원 2년 및 보안 수정 3년입니다.
• 매년 10월에 릴리스하는 주기도 변경하지 않습니다.

사양

Python 버전은 3.YY.micro 형식으로 번호를 매깁니다:

• 3은 주 버전 번호이며 항상 3입니다.
• YY은 부 버전 번호입니다. - 단축 연도 번호인 {year} - 2000입니다.
• micro는 마이크로 버전 번호입니다. - 각 버그 수정 또는 보안 릴리스마다 증가합니다.

주 버전 3을 유지합니다. Python 3이 브랜드이며 Python 4는 없습니다.

2100년에는 부 버전이 2100-2000 = 100이 되므로 버전은 3.100.0이 됩니다.

Python 3.14는 이 변경 전 마지막 버전으로 2025년에 릴리스됩니다. Python 3.26은 이 변경 후 첫 번째 버전으로 2026년에 릴리스됩니다. Python 3.15부터 3.25까지의 버전은 없습니다.

보안 관련 영향

알려진 영향은 없습니다. 버그 수정 및 보안 단계의 기간이나 시점에는 변경이 없습니다.

이 내용을 가르치는 방법

블로그, 3.14 릴리스 노트, 문서 및 커뮤니티 대상 활동을 통해 이를 알립니다.

이 변경은 3.14 다음 버전을 대상으로 합니다. 3.15 대신 3.26이 됩니다. 이 PEP는 2024년 6월에 제안되었습니다. 3.15/3.26 릴리스 개발은 2025년 5월에 시작되며, 첫 알파는 2025년 10월에, 최초 릴리스는 2026년 10월에 제공됩니다. 3.14 주기 동안 이미 문서를 업데이트할 수 있습니다. 따라서 충분한 사전 고지가 이루어집니다.

조기 테스트를 위해 버전만 변경한 프리뷰 빌드를 만들 수 있습니다.

Python 3.26의 일부로 python3.15 명령을 제공하여 즉시 오류를 발생시키고 대신 python3.26을 사용하라고 알릴 수 있습니다.

기각된 아이디어

YY.0

예를 들어 Python 26.0은 2026년에 릴리스됩니다.

Python 버전 4에 대한 열의는 그다지 크지 않습니다. 2에서 3으로의 전환을 되풀이하고 싶지 않습니다, 현재 4에는 많은 기대가 걸려 있습니다. “세상을 뒤흔드는 변화”는 원하지 않습니다.

아마도 Python 4는 GIL 제거(PEP 703)와 같은 큰 변화를 위해 남겨 둘 수 있지만, Steering Council은 자유 스레딩의 도입은 점진적이어야 한다는 점을 분명히 했습니다. 버전 3을 영원히 고수할까요?

또 다른 방법은 연도를 주 버전에 넣고 26.0으로 건너뛰는 것입니다. 이렇게 하면 4.0에 수반되는 모든 부담을 건너뛸 수 있습니다.

플랫폼 호환성 태그

그러나 주 버전을 변경하면 패키징이 복잡해집니다.

패키징 사양인 Platform compatibility tags에서는 휠 파일 이름에 사용되는 Python 버전 태그가 sysconfig.get_config_var("py_version_nodot")로 지정된다고 설명하며, 주 버전과 부 버전은 점 없이 이어집니다. 예를 들어 3.9는 39입니다.

3.10 알파 기간에는 310을 3.10, 31.0 또는 310으로 해석할 수 있어 모호성이 있었습니다.

명세에서는 필요한 경우 밑줄을 사용할 수 있다고 명시하며, PEP 641(“Python 3.10 호환성 태그의 버전 부분에 밑줄 사용하기”)에서는 다음과 같이 제안했습니다:

	버전 → 태그 → 버전	PEP 641에서 제안한 버전
3.10 이전	3.9 → 39
3.10 이후의 모호함	3.10 → 310 → 3.10인지 31.0인지 310인지?	3_10
YY.xx와의 모호함	26.0 → 260 → 2.60인지 26.0인지 260인지?	26_0

그러나 PEP 641은 우리가 알지 못하는 코드에 어떤 부작용이 있을지 알 수 없다는 이유로 거부되었습니다.

YY.0 버전 관리에는 이와 같은 것이 필요하며, 이는 상당히 복잡하고 많은 작업을 요구합니다.

생태계 변경

주 버전을 두 자리 숫자로 변경하면 코드가 손상됩니까?

예, 버전에 대한 새로운 변경은 무엇이든 필연적으로 그러한 결과를 초래합니다. 주 버전은 항상 3이라고 가정하거나 버전 구성 요소가 항상 한 자리 숫자라고 가정하는 등 사람들이 여러 가지 가정을 하기 때문입니다. 예를 들면 다음과 같습니다.

Version change	Example	Expected	Actual
2.7.9 → 2.7.10	'this is Python {}'.format(sys.version[:5])	2.7.10	2.7.1
3.9 → 3.10	".%s-%s" % (get_platform(), sys.version[0:3])	3.10	3.1
3 → 4	if sys.version_info[1] >= 9:	4.0	0
3 → 26	if sys.version[0] == '3':	26	2

여기서 마지막 항목이 YY.0 버전 관리와 가장 관련이 깊습니다. 따라서 3.YY 체계가 가장 안전하고 변경 사항도 가장 적습니다. 버전의 형태가 바뀌지 않기 때문입니다. 여전히 3 뒤에 두 자리 숫자가 오는 형태입니다.

Tip

이와 같은 문제를 찾는 데 도움이 되도록 Ruff의 YTT 규칙 또는 Flake8의 flake8-2020 플러그인을 사용하십시오.

python3 명령

PEP 394(유닉스 계열 시스템의 “python” 명령)은 python, python2 및 python3 명령에 대한 권고 사항을 제시합니다. python은 python2 또는 python3에 매핑될 수 있습니다. 주 버전이 변경되고 매년 바뀌기 시작한다면 이러한 사항을 재검토해야 합니다.

Python 2.7이 지원 종료된 지 4년이 지나면 python은 최신 Python 3+ 버전에만 매핑되도록 권고할 수 있습니다. 그러나 Python 26.0이 출시되면 python3은 어디에 매핑해야 합니까? 이렇게 하면 복잡성과 비용이 추가됩니다.

CPython 변경 사항

python3 명령 변경 외에도 CPython에는 주 버전이 3이라고 가정하여 업데이트해야 하는 부분이 최소 네 곳 있습니다.

• Lib/ast.py
• Parser/pegen.c
• Parser/pegen.h
• Parser/string_parser.c

YY.0 기각

달력 버전 관리의 이점은 YY.0 버전 관리에 수반되는 비용을 모두 합한 것에 비하면 그리 크지 않습니다. 따라서 YY.0 버전 관리는 기각됩니다.

YY.MM

예를 들어 Python 26.10은 2026년 10월에 릴리스됩니다.

YY.0 버전 관리를 기반으로 Ubuntu 및 Black과 같이 릴리스 월을 마이너 버전으로 포함할 수도 있습니다. 이렇게 하면 해당 버전이 연중 언제 릴리스되었는지, 그리고 연중 언제 수명 종료에 도달할지도 명확해집니다.

그러나 YY.MM 버전 관리는 YY.0 버전 관리와 동일한 여러 이유로 거부됩니다.

3.YYYY

예를 들어 Python 3.2026은 2026년에 릴리스됩니다.

네 자리 숫자를 사용하면 마이너 버전이 연도라는 점이 더 명확해지고, YY.MM을 사용하는 Ubuntu 버전과의 혼동도 피할 수 있습니다.

PY_VERSION_HEX

CPython의 C API PY_VERSION_HEX 매크로는 현재 마이너 버전을 인코딩하는 데 8비트를 사용하며, 최대 마이너 버전까지 수용하도록 하고 있습니다. 255. 네 자리 연도를 담으려면 2047에 맞도록 11비트로 확장하거나 더 정확히는 4095에 맞도록 12비트가 필요합니다.

이는 #if PY_VERSION_HEX >= ...와 같은 수치 비교를 위한 것이므로 실현 가능해 보입니다. 상위 8,000개 PyPI 프로젝트에서는 비트 시프트(hexversion >> 16 != PY_VERSION_HEX >> 16)의 사례가 단 하나만 발견되었습니다.

그러나 3.YYYY는 두 자리에서 네 자리로 변경하려면 더 많은 작업이 필요하고, 더 단순한 3.YY 버전 관리보다 더 많은 코드를 손상시키므로 거부됩니다.

에디션

예를 들어 Python 3.15(2026 Edition)는 2026년에 릴리스됩니다.

Rust 언어는 호환성을 깨는 변경 사항을 도입하기 위해 “Editions”을 사용합니다. 이를 Python에 적용하려면 PEP 387(하위 호환성 정책)을 크게 변경해야 하며, 이는 이 PEP의 범위를 벗어납니다.

“Python 3.15 (2026 Edition)”과 같이 릴리스에 연도 레이블을 적용할 수도 있지만, 숫자 두 개를 추적해야 하므로 이는 거부됩니다.

SemVer를 채택하고 4를 건너뛰기

예를 들어 Python 5.0은 2026년에, 6.0은 2027년에 릴리스되는 식입니다.

문제가 되는 4.0을 완전히 건너뛰고 SemVer를 채택할 수도 있습니다. 각 기능 릴리스에서 지원 중단된 항목이 제거되므로 매년 새로운 주요 버전 상승이 발생하게 됩니다.

이는 달력 버전 관리의 이점을 얻을 수 없고, 3.x에서 벗어나는 것 또한 break code를 발생시키므로 거부됩니다.

3.14 주기 중 변경

Python 3.14 릴리스는 다음과 같은 이유로 진행되어야 합니다: π.

하위 호환성

이 버전 변경은 검토된 CalVer 옵션 중 가장 안전합니다(rejected ideas 참조). 주요 버전으로 3을 유지하고, 마이너 버전도 여전히 두 자리로 유지하기 때문입니다. 마이너 버전은 결국 세 자리로 변경되지만, 이는 예측 가능하고 아직 먼 미래의 일이므로 계획을 세울 수 있습니다.

python3 실행 파일을 유지합니다.

버전 매핑

3.15부터 3.25까지의 버전이 모두 건너뛰어집니다. 이 버전들에 계획된 기능, 사용 중단 및 제거가 새 버전 번호에 맞게 다시 매핑됩니다.

예를 들어, 처음에 3.16에서 제거할 예정이었던 사용 중단 항목은 대신 3.27에서 제거됩니다.

이전 버전	새 버전	최초 릴리스
3.14	3.14 (변경 없음)	2025
3.15	3.26	2026
3.16	3.27	2027
3.17	3.28	2028
3.18	3.29	2029
3.19	3.30	2030
3.20	3.31	2031
3.21	3.32	2032
3.22	3.33	2033
3.23	3.34	2034
3.24	3.35	2035
3.25	3.36	2036

전방 호환성

향후 릴리스 주기 변경

이 PEP는 PEP 602에서 정의한 연간 릴리스 주기를 변경하지 않을 것을 제안합니다. 해당 문서는 연간 릴리스를 위한 여러 가지 타당한 이유를 설명합니다(예를 들어, 예측 가능한 릴리스 일정에 따른 더 작은 릴리스와 외부 재배포자와의 동기화가 있습니다). 가능성은 낮지만 향후 릴리스 주기를 변경하기로 결정하더라도 CalVer는 이를 막지 않습니다.

더 드문 릴리스

연간 릴리스가 한 번보다 적은 경우에도 제안된 CalVer 체계는 계속 작동합니다. 실제로 릴리스를 어느 해에 예상해야 하는지 아는 데에도 도움이 됩니다. 예를 들어 2036년부터 2년에 한 번씩 릴리스한다면 다음과 같습니다.

• 3.36.0은 2036년에 릴리스됩니다.
• 3.38.0은 2038년에 릴리스됩니다.
• 그 이후에도 같은 방식으로 계속됩니다.

생태계 변경 사항은 가상의 릴리스 주기 변경 PEP가 PEP 387 (하위 호환성 정책)을 어떻게 업데이트하는지에 부분적으로 달려 있습니다. 예를 들어 최소 2년을 유지하기 위해 지원 중단 기간을 현재의 2회가 아니라 최소 1회의 기능 릴리스로 요구한다면, CalVer는 계획된 제거 버전을 변경할 필요가 없다는 점에서 현재 방식보다 이점이 있습니다(릴리스가 없는 연도에 해당하는 버전은 조정해야 합니다).

더 잦은 릴리스

연간 릴리스가 한 번보다 많은 경우에는 다음과 같은 선택지가 있습니다. 예를 들어 2036년부터 4월과 10월에 릴리스한다면 다음 네 번의 릴리스는 다음과 같을 수 있습니다.

Scheme	Notes	2036 a	2036 b	2037 a	2037 b
YY.MM.micro	Year as major, month as minor	36.04.0	36.10.0	37.04.0	37.10.0
YY.x.micro	Year as major, serial number as minor	36.1.0	36.2.0	37.1.0	37.2.0
3.YYMM.micro	Combine year and month as minor	3.3604.0	3.3610.0	3.3704.0	3.3710.0
3.YYx.micro	Combine year and serial number as minor	3.360.0	3.361.0	3.370.0	3.371.0
3.YY.MM.micro	Add an extra month segment	3.36.04.0	3.36.10.0	3.37.04.0	3.37.10.0
3.major.micro	No more CalVer: increment minor	3.36.0	3.37.0	3.38.0	3.39.0
		3.50.0	3.51.0	3.52.0	3.53.0
		3.100.0	3.101.0	3.102.0	3.103.0
4.major.micro	No more CalVer: increment major	4.0.0	4.1.0	4.2.0	4.3.0
5.major.micro		5.0.0	5.1.0	5.2.0	5.3.0

YY 옵션을 사용하려면 플랫폼 호환성 태그를 둘러싼 문제, python3 명령과 버전이 항상 3으로 시작한다고 가정하는 코드를 해결해야 합니다.

주 버전 3은 유지하면서 부 버전을 세 자리 또는 네 자리로 변경하는 옵션에서도 버전이 항상 두 자리라고 가정하는 코드를 처리해야 합니다.

월을 나타내는 세그먼트를 하나 추가하는 옵션은 코드가 세 부분 버전 대신 네 부분 버전을 처리해야 하므로 가장 큰 변경입니다.

CalVer를 없애는 옵션은 주 버전과 부 버전을 자유롭게 선택할 수 있으므로 가장 보수적입니다.

CalVer 폐지

지금 CalVer를 도입해도 향후 CalVer에서 벗어나는 것이 배제되지는 않으며, 예를 들어 원래 체계, SemVer 또는 다른 체계로 되돌아갈 수 있습니다. 일부 선택지는 위 표에 나열되어 있습니다. 마이너 버전이 더 이상 연도를 의미하지 않는다는 점을 분명히 하려면, 이를 더 높은 어림수(예: 3.50 또는 3.100)로 올리거나 메이저 버전을 올릴 수 있습니다(예: 4.0 또는 5.0). 추가로, 버전 에포크도 고려할 수 있습니다.

각주

저자는 Python 언어 정상회의 2024에서 달력 버전 관리를 제안했으며; 이 PEP는 해당 회의와 PyCon US에서 이루어진 논의의 결과입니다.

정상회의 발표의 슬라이드와 블로그 게시물을 읽으십시오.

감사의 말

Language Summit Q&A 메모와 블로그 게시물을 제공해 주신 Seth Michael Larson과, 정상회의 및 PyCon US에서 의견을 보내 주신 모든 분께 감사드립니다.

이 PEP의 초안을 검토해 주신 Łukasz Langa와 Alex Waygood께 감사드립니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.