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 버전을 지원할지 판단하기가 더 쉬워집니다.

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

• 2026년에는 Python 3.15 대신 Python 3.26이 릴리스됩니다. EOL은 최초 릴리스 후 5년이므로 Python 3.26은 2031년에 EOL에 도달합니다.
• 2027년에는 Python 3.27이 릴리스되며, 이후에도 같은 방식입니다.

동기와 근거

2019년에 우리는 PEP 602로 연간 릴리스 주기를 도입했으며, 이로써 캘린더 버전 관리의 길이 열렸습니다:

연간 릴리스 일정을 도입하면 자연스럽게 캘린더 버전 관리로 전환할 수 있습니다. 예를 들어 Python 3.9는 ‘20년 10월에 릴리스되므로 “Python 3.20”이라고 부르는 식이며, 이후에도 마찬가지입니다(“Python 3.23”은 ‘23년 10월에 릴리스되는 버전이 됩니다).

캘린더 버전 관리로 쉽게 전환할 수 있다는 점을 연간 릴리스 주기의 장점으로 볼 수는 있지만, 이 PEP는 Python의 버전 관리 방식을 바꾸는 것에 찬성하지도 반대하지도 않습니다. 연간 릴리스 주기가 채택된다면 버전 관리 문제는 별도의 PEP에서 다룰 것입니다.

이 문서가 바로 그 PEP입니다.

현재 체계

일반 Python FAQ에서 발췌: How does the Python version numbering scheme work?

Python 버전 번호는 “A.B.C” 또는 “A.B” 형식입니다:

• A는 메이저 버전 번호입니다 – 언어에 정말 중대한 변경이 있을 때만 증가합니다.
• B는 마이너 버전 번호입니다 – 그보다 덜 획기적인 변경이 있을 때 증가합니다.
• C는 마이크로 버전 번호입니다 – 버그 수정 릴리스마다 증가합니다.

Python은 SemVer보다 먼저 만들어졌습니다

유의적 버전 (SemVer)은 릴리스의 의도를 전달하는 것을 목표로 하는 널리 쓰이는 체계입니다(다만 항상 성공하는 것은 아닙니다).

버전 번호가 MAJOR.MINOR.PATCH일 때, 다음과 같이 증가시킵니다:

1. 호환되지 않는 API 변경을 할 때는 메이저 버전(MAJOR)을 올립니다
2. 하위 호환성을 유지하면서 기능을 추가할 때는 MINOR 버전
3. 하위 호환되는 버그 수정을 할 때는 패치 버전(PATCH)을 올립니다

사람들은 흔히 파이썬이 SemVer를 따른다고 가정하고 기능 릴리스의 호환성을 깨는 변경에 대해 불평합니다. 하지만 파이썬은 SemVer보다 적어도 15년 먼저 등장했습니다. SemVer 명세는 2009년에 도입되었고, 파이썬 고유의 체계는 1.0 릴리스를 위해 1994년에 소스 관리에 추가되었습니다.

Python이 SemVer를 채택한다면 폐지된 기능을 제거하는 매년 메이저 버전을 새로 올려야 한다는 뜻이 됩니다.

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

달력 버전 관리

달력 버전 관리 (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

지원 수명 주기의 명확성

현재는 릴리스가 언제 지원 종료(end-of-life)되는지 알아내기가 조금 까다롭습니다. 먼저 최초 릴리스 시점을 찾아본 다음 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”

설치 시기의 명확성

버전에 연도가 들어 있으면 설치된 Python이 얼마나 오래되었는지 파악하기가 더 쉽습니다. 예를 들어, 현재 체계에서는 2035년에 Python 3.15를 사용하고 있다면, 그것이 2026년에 처음 릴리스되었다는 사실(그리고 2031년부터 EOL 상태였다는 사실)이 바로 드러나지 않습니다.

CalVer를 알고 있다면, 2035년에 Python 3.26을 사용하고 있을 때 그것이 9년 전에 처음 릴리스되었으며 아마도 업그레이드할 때가 되었다는 것이 분명합니다.

이는 사람들이 아직 보안 지원을 받는 지원 대상 릴리스로 전환하도록 유도하는 데 도움이 되고, 오래된 설치본을 가지고 있을 수 있는 신규 사용자를 교육하는 데에도 도움이 됩니다.

버전 지원의 명확성

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

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

그러나 CalVer를 사용하면 2031년에 최솟값을 3.30으로 설정할 때 이 점이 더 분명해집니다. 더 폭넓은 지원을 원한다면 3.26으로 설정하는 편을 선호할 수도 있습니다.

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

예를 들어, 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.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)와 같은 큰 변화를 위해 남겨 둘 수도 있겠지만, 운영 위원회는 프리 스레딩 도입이 점진적이어야 한다는 점을 분명히 했습니다. 우리는 영원히 버전 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(Unix 계열 시스템의 “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 에디션)는 2026년에 릴리스됩니다.

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

“Python 3.15 (2026 에디션)”처럼 릴리스에 연도 라벨을 붙일 수도 있지만, 그러면 두 개의 숫자를 추적해야 하므로 이 방안은 거부되었습니다.

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

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

문제가 되는 4.0을 완전히 건너뛰고 SemVer를 채택할 수도 있습니다. 모든 기능 릴리스에서 폐지된 기능이 제거되므로 매년 메이저 버전을 새로 올리게 됩니다.

이 방안은 거부되었습니다. 달력 버전 관리의 이점을 얻을 수 없고, 3.x에서 벗어나는 것 역시 코드를 깨뜨릴 것이기 때문입니다.

3.14 주기 중에 변경하기

Python 3.14 릴리스는 반드시 예정대로 진행되어야 합니다. 이유는 π이기 때문입니다.

하위 호환성

이 버전 변경은 검토한 CalVer 방안 중 가장 안전합니다(거부된 아이디어 참고). 메이저 버전은 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에 정의된 연간 릴리스 주기를 바꾸자고 제안하지 않습니다. 해당 PEP는 연간 릴리스를 해야 하는 여러 타당한 이유를 제시합니다(예를 들어, 예측 가능한 릴리스 일정에 따른 더 작은 규모의 릴리스, 외부 재배포자와의 일정 동기화 등). 가능성은 낮지만, 향후 릴리스 주기를 변경하기로 결정하더라도 CalVer가 이를 가로막지는 않습니다.

더 드문 릴리스

1년에 한 번보다 적게 릴리스하게 되더라도 제안된 CalVer 체계는 여전히 유효합니다. 오히려 어느 해에 릴리스를 기대할 수 있는지 알기가 더 쉬워집니다. 예를 들어 2036년부터 2년마다 릴리스한다면 다음과 같습니다.

• 3.36.0은 2036년에 릴리스됩니다
• 3.38.0은 2038년에 릴리스됩니다
• 이런 식으로 계속됩니다.

생태계 변화는 릴리스 주기를 변경하는 가상의 PEP가 PEP 387 (하위 호환성 정책)을 어떻게 갱신하는지에 따라 일부 달라집니다. 예를 들어, 그 PEP가 폐지 기간을 현재의 두 기능 릴리스가 아니라 최소 한 기능 릴리스로 하도록 요구한다면(최소 2년을 유지하기 위해), CalVer는 계획된 제거 버전을 바꿀 필요가 없다는(릴리스가 없는 연도에 해당하는 것을 조정하는 것 외에는) 점에서 현 상태보다 이점이 있습니다.

더 잦은 릴리스

1년에 두 번 이상 릴리스하게 된다면 다음과 같은 선택지가 있습니다. 예를 들어 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 Language Summit 2024에서 캘린더 버전 관리를 제안했으며, 이 PEP는 그 자리와 PyCon US 기간 중에 있었던 논의의 결과입니다.

서밋 발표의 슬라이드와 블로그 글을 읽어 보십시오.

감사의 글

Language Summit 질의응답 기록과 블로그 글을 작성해 주신 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.