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

Python 개선 제안 한국어 번역

PEP 598 – 점진적 기능 릴리스 소개

Author:
Alyssa Coghlan <ncoghlan at gmail.com>
Discussions-To:
Discourse thread
Status:
Withdrawn
Type:
Informational
Created:
15-Jun-2019
Python-Version:
3.9
Table of Contents

번역·라이선스 안내

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

초록

PEP 602는 Python 표준 라이브러리와 CPython 참조 인터프리터의 기능 제공 지연 시간을 줄이기 위해 CPython 기능 릴리스의 주기를 18~24개월마다에서 9~12개월마다로 늘릴 것을 제안합니다.

이 PEP는 새로운 기준 기능 릴리스(이와 관련된 파일 시스템 레이아웃 변경, 바이트코드 형식 변경 및 C ABI 호환성 중단을 수반함)가 발생하는 빈도를 대신 격년(2020, 2022, 2024, etc)으로만 줄이고, 이러한 변경을 특정 릴리스 계열의 최초 포인트 릴리스 집합에 하위 호환 기능을 도입할 수 있도록 하는 새로운 정책 및 접근 방식과 결합할 것을 제안합니다.

PEP 철회

이 PEP는 PEP 605의 롤링 베타 릴리스 스트림 제안을 지지하는 방향으로 철회되었습니다.

그러나 이 PEP에서 제기된 우려 사항은 이러한 릴리스를 지원하는 개발자 경험을 개선하기 위해 기능 백포트를 허용하는 다른 “장기 지원 브랜치” 제안(예: [3]의 EL Python 초안)에도 적용될 가능성이 높으므로, 여기 제시된 아이디어는 그러한 제안에 유용한 설계 제안을 제공할 수 있습니다.

요약

현재 CPython 릴리스 호환성 관리 프로세스를 유지하되 이를 더 자주 수행하자는 제안에는 상당한 실질적 단점이 있습니다. CPython 기능 릴리스에는 특정한 기대 사항(특히 5년의 유지 관리 수명 주기, 이전 기능 릴리스와의 병렬 설치 지원, 그리고 모든 확장 모듈의 재컴파일이 필요한 CPython 전용 ABI의 호환성 중단 가능성)이 따르므로, 현재 형태의 더 빠른 기능 릴리스는 지원되는 모든 CPython 릴리스 전반에서 서드파티 Python 라이브러리와 애플리케이션을 유지 관리하는 부담을 크게 늘릴 가능성이 있습니다.

또한 이러한 접근 방식이 실제로 대부분의 최종 사용자가 체감하는 일반적인 기능 제공 지연 시간을 눈에 띄게 줄일 수 있을지는 논쟁의 여지가 있습니다. 새로운 기능 릴리스의 도입 주기는 일반적으로 수개월 또는 수년 단위로 측정되므로, 릴리스가 더 잦아지면 최종 사용자는 현재 흔히 발생하는 것처럼 두 번째 또는 세 번째 기능 릴리스마다 업데이트하는 대신 세 번째 또는 네 번째 기능 릴리스마다 업데이트하게 될 수 있습니다.

이 PEP는 파일 시스템 레이아웃과 CPython ABI를 변경하는 병렬 설치 가능 기능 릴리스의 주기를 일관된 24개월 주기로 대신 늦추는 경쟁 제안을 제시합니다. 이를 보완하기 위해 빌드 호환 가능한 점진적 기능 릴리스라는 개념을 도입하고, 특정 기능 릴리스 시리즈의 완전한 기능 동결을 초기 기준 X.Y.0 릴리스에서 초기 기준 기능 릴리스 후 약 12개월 뒤에 이루어지는 후속 X.Y.Z 기능 완성 릴리스까지 연기합니다.

sys.version_info 구조의 새로운 feature_complete 특성은 릴리스 시리즈가 추가 점진적 기능 릴리스에 계속 열려 있는지 여부를 프로그래밍 방식으로 나타냅니다. Python의 대체 구현은 해당 구현의 명목상 Python 버전에 대한 지원이 아직 작업 중일 수 있음을 나타내기 위해 이 플래그를 해제할 수도 있습니다.

호환성 테스트를 수행하고 혼합 버전 환경에서 pickle 호환성을 유지하기 위해 새로운 sys.feature_limit 특성(및 이에 대응하는 CPython CLI 매개변수 --feature-limit X.Y.Z와 환경 변수 PYTHONFEATURELIMIT)은 점진적 기능 릴리스에 추가된 기능의 런타임 사용 가능 범위를 제한하는 방법을 제공합니다.

기존 주기와 새 주기는 기능 동결 릴리스 날짜를 기준으로 동기화됩니다. 따라서 전체 Python 3.9.x 기능 동결은 Python 3.8.0 기능 릴리스 후 24개월이 지난 2021년 10월에 이루어지고, 최초의 Python 3.9.0 릴리스는 2020년 10월에 진행됩니다.

향후 릴리스 일정 예시

이 제안에 따르면 Python 3.9.0a1은 2019년 10월의 Python 3.8.0 기능 완성 릴리스 직후인 2019년 11월에 릴리스됩니다.

그런 다음 3.9.0b1 릴리스가 6개월 후인 2020년 5월에 이루어지고, 3.9.0 자체는 2020년 10월에 릴리스됩니다.

3.9.x의 마이크로 릴리스가 분기별로 이루어진다고 가정하면 전체 릴리스 일정은 다음과 같습니다.

  • 2019-11: 3.9.0a1
  • … 릴리스 관리자가 결정하는 추가 알파 릴리스
  • 2020-05: 3.9.0b1
  • … 릴리스 관리자가 결정하는 추가 베타 릴리스
  • 2020-08: 3.9.0bX (ABI 호환성을 고정하는 최종 베타 릴리스)
  • 2020-09: 3.9.0rc1
  • … 릴리스 관리자가 결정하는 추가 릴리스 후보
  • 2020-10: 3.9.0 (BFR - 기준 기능 릴리스)
  • 2021-01: 3.9.1 (IFR - 점진적 기능 릴리스)
  • 2021-04: 3.9.2 (IFR)
  • 2021-07: 3.9.3 (IFR)
  • 2021-10: 3.9.4 (기능 완성 릴리스)
  • 2022-01: 3.9.5
  • 2022-04: 3.9.6
  • 2022-07: 3.9.7
  • 2022-10: 3.9.8 (최종 정기 유지 관리 릴리스)
  • … 필요에 따라 추가 보안 수정 전용 릴리스
  • 2025-10: 3.9.x 브랜치 종료

기능 완성 릴리스 번호는 일반적으로 한정자 없이 작성되지만(현재와 같이), 베이스라인 및 증분 기능 릴리스에는 전통적인 CPython 릴리스가 아님을 나타내는 한정자를 덧붙일 것으로 예상됩니다(3.9.0 (BFR), 3.9.1 (IFR) 등).

Python 3.10 릴리스 시리즈는 첫 번째 Python 3.9 기능 완성 릴리스가 나온 다음 달부터 게시되기 시작하며, Python 3.9의 정기 유지 관리 릴리스 마지막 12개월과 병행하여 진행됩니다:

  • 2021-11: 3.10.0a1
  • … 릴리스 관리자가 결정하는 추가 알파 릴리스
  • 2022-05: 3.10.0b1
  • … 릴리스 관리자가 결정하는 추가 베타 릴리스
  • 2022-08: 3.10.0bX (ABI 호환성을 고정하는 최종 베타 릴리스)
  • 2022-09: 3.10.0rc1
  • … 릴리스 관리자가 결정하는 추가 릴리스 후보
  • 2022-10: 3.10.0 (BFR)
  • 2023-01: 3.10.1 (IFR)
  • 2023-04: 3.10.2 (IFR)
  • 2023-07: 3.10.3 (IFR)
  • 2023-10: 3.10.4
  • 2024-01: 3.10.5
  • 2024-04: 3.10.6
  • 2024-07: 3.10.7
  • 2024-10: 3.10.8 (최종 정기 유지 관리 릴리스)
  • … 필요에 따라 추가 보안 수정 전용 릴리스
  • 2027-10: 3.10.x 브랜치 종료

이 모델에서는 항상 두세 개의 활성 브랜치가 존재합니다:

  • 2019-04 -> 2019-10: 3.9.0 프리알파, 3.8.0 프리릴리스, 3.7.x 유지 관리
  • 2019-10 -> 2020-05: 3.9.0 프리베타, 3.8.x 유지 관리
  • 2020-05 -> 2020-10: 3.10.0 프리알파, 3.9.0 프리릴리스, 3.8.x 유지 관리
  • 2020-10 -> 2021-10: 3.10.0 프리알파, 3.9.x 기능 릴리스, 3.8.x 유지 관리
  • 2021-10 -> 2022-05: 3.10.0 프리베타, 3.9.x 유지 관리
  • 2022-05 -> 2022-10: 3.11.0 프리알파, 3.10.0 프리릴리스, 3.9.x 유지 관리
  • 2022-10 -> 2023-10: 3.11.0 프리 알파, 3.10.x 기능 릴리스, 3.9.x 유지보수입니다
  • 2023-10 -> 2024-05: 3.11.0 프리 베타, 3.10.x 유지보수입니다
  • 2024-05 -> 2024-10: 3.12.0 프리 알파, 3.11.0 프리 릴리스, 3.10.x 유지보수입니다
  • … 기타입니다

프리 알파 및 프리 베타 개발은 메인 git 브랜치에서 이루어지고, 그 밖의 모든 개발은 릴리스별 브랜치에서 이루어지며 변경 사항은 일반적으로 메인 git 브랜치에서 백포트됩니다.

TODO: 이를 설명하는 데 도움이 되도록 다이어그램이 정말 필요하므로, 추가할 그림이 생기면 그림을 추가하겠습니다.

이는 현 상태와 상당히 유사하지만, 더 일관된 주기로 진행되며, 새로운 기준 기능 릴리스의 알파 및 베타 주기에 중점을 두는 기준 기능 릴리스 연도(2020년, 2022년 등)와 이전 기능 릴리스 계열의 유지보수 릴리스를 계속 게시하는 연도, 그리고 현재 기능 릴리스 계열에 소규모 개선을 적용하면서 다음 해의 다음 기능 릴리스 계열을 계획하는 기능 완성 릴리스 연도(2021년, 2023년 등)가 번갈아 나타납니다.

제안입니다

알파 및 베타 릴리스를 제외하면 CPython에는 현재 3가지 서로 다른 릴리스 증분 유형이 있습니다.

  • 기능 릴리스입니다(즉, X.Y.0 릴리스입니다).
  • 유지보수 릴리스입니다(X.Y.0 이후 ~2 years 이내의 X.Y.Z 릴리스입니다).
  • 소스 전용 보안 릴리스입니다(이후의 X.Y.Z 릴리스입니다).

기능 동결은 X.Y.0b1 릴리스 시점에 이루어집니다. 빌드 호환성 동결은 이제 마지막 베타 릴리스 시점에 이루어지며, 첫 번째 릴리스 후보 이전에 프로젝트가 PyPI에 휠 아카이브를 업로드할 시간을 제공합니다.

그러면 릴리스 계열의 수명 주기에 다음과 같은 기간이 생성됩니다.

  • 프리 베타입니다(릴리스 계열은 CPython 개발 브랜치입니다).
  • 베타입니다(릴리스가 유지보수 모드로 전환되고 ABI 호환성이 대부분 고정됩니다).
  • 유지보수입니다(ABI가 고정되며 버그 수정 및 문서 개선만 허용됩니다).
  • 보안 수정만 가능합니다(추가 바이너리 릴리스는 없으며 보안 수정만 허용됩니다).
  • 수명 종료입니다(어떠한 종류의 릴리스도 더 이상 제공되지 않습니다).

이 PEP의 제안은 “기능 릴리스” 범주를 세 가지 서로 다른 기능 릴리스 유형으로 나누자는 것입니다.

  • 기준 기능 릴리스입니다(X.Y.0 릴리스입니다).
  • 증분 기능 릴리스입니다(기준 기능 릴리스와 해당 기능 완성 릴리스 사이에 게시되는 모든 X.Y.Z 릴리스입니다).
  • 기능 완성 릴리스입니다(X.Y.0 이후 ~1 year 후의 특정 X.Y.Z 릴리스입니다).
  • 유지보수 릴리스입니다(기능 완성 릴리스 이후 ~1 years 이내의 X.Y.Z 릴리스입니다).
  • 소스 전용 보안 릴리스입니다(이후의 X.Y.Z 릴리스입니다).

그러면 릴리스 계열 수명 주기에 새로운 “기능 릴리스” 단계가 도입됩니다.

  • 프리 베타입니다(릴리스 계열은 CPython 개발 브랜치입니다).
  • 베타입니다(릴리스가 기능 추가 모드로 전환되며 ABI 호환성은 아직 고정되지 않습니다).
  • 기능 릴리스입니다(ABI가 고정되고 하위 호환 가능한 API 추가가 허용됩니다).
  • 유지보수입니다(ABI가 고정되며 버그 수정 및 문서 개선만 허용됩니다).
  • 보안 수정만 가능합니다(추가 바이너리 릴리스는 없으며 보안 수정만 허용됩니다).
  • 수명 종료(어떤 종류의 릴리스도 더 이상 없음)

사전 릴리스 베타 기간에는 더 엄격한 유지보수 릴리스 정책 대신 변경 사항에 증분 기능 릴리스 정책을 사용하도록 완화됩니다.

거버넌스 목적상 기준 기능 릴리스만 PEP 13의 의미에서 “기능 릴리스”에 해당하는 유일한 릴리스입니다(증분 기능 릴리스는 포함되지 않습니다).

기준 기능 릴리스 및 기능 릴리스 시리즈

기준 기능 릴리스는 본질적으로 기존 기능 릴리스에 새 이름을 부여한 것으로, 새로운 증분 기능 릴리스와 구별하는 데 도움을 주며, 또한 기존 릴리스와 달리 릴리스 시점에 더 이상 기능이 완성된 것으로 간주되지 않음을 나타내는 데 도움을 줍니다.

기준 기능 릴리스는 계속해서 새로운 기능 릴리스 시리즈를 정의하며, 해당 시리즈의 나머지 기간 동안 다음 언어, 빌드 및 설치 호환성 제약을 고정합니다.

  • Python 언어 문법
  • ast 모듈 AST 형식
  • CPython 인터프리터 opcode 형식
  • pyc 파일 매직 넘버 및 파일 이름 호환성 태그
  • 확장 모듈 파일 이름 호환성 태그
  • wheel 아카이브 호환성 태그
  • 기본 패키지 및 모듈 임포트 디렉터리
  • 기본 설치 파일 이름 및 디렉터리

기준 기능 릴리스는 또한 다음을 수행할 수 있는 유일한 릴리스로 계속 유지됩니다.

  • 새로운 사용 중단 예정, 보류 중인 사용 중단 예정 및 기타 경고를 도입할 수 있습니다.
  • 기존 보류 중인 사용 중단 예정을 완전한 사용 중단 예정으로 전환할 수 있습니다.
  • 기존 경고를 오류로 전환할 수 있습니다.
  • What’s New 문서에 “Porting to Python X.Y” 항목이 필요한 기타 변경 사항을 도입할 수 있습니다.

기능 릴리스 시리즈의 주요 특징:

  • 하나의 기능 릴리스 시리즈 내 설치는 다른 기능 릴리스 시리즈의 설치와 충돌하지 않습니다(즉, 병렬로 설치할 수 있습니다).
  • 기능 릴리스 시리즈 내 설치는 이미 설치된 구성 요소를 다시 설치하거나 그 밖의 변경을 하지 않고도 동일한 시리즈 내 이후 마이크로 릴리스로 업데이트할 수 있습니다.

기준 기능 릴리스의 주요 특징:

  • 기준 기능 릴리스에서 sys.version_info.feature_complete == False입니다.
  • 기준 기능 릴리스에서 sys.version_info.micro == 0입니다.
  • 기준 기능 릴리스에는 문법 수정, 인터프리터 및 표준 라이브러리 내부의 대규모 리팩터링 또는 기존의 다른 기능에 의도하지 않은 부작용을 일으킬 위험이 있는 잠재적으로 침해적인 기능 추가와 같이 언어 및 인터프리터에 대한 더 높은 위험의 변경 사항이 포함될 수 있습니다.
  • 기준 기능 릴리스에 도입된 기능은 sys.version_info에 해당 기능의 사용 가능 여부를 나타내는 유일한 런타임 지표로 의존할 수 있도록 허용된 오직 기능입니다.

기능 릴리스 시리즈 및 기준 기능 릴리스에 대한 주요 기대 사항:

  • 대부분의 공개 프로젝트는 릴리스 시리즈 내 가장 최근 마이크로 릴리스에 대해서만 적극적으로 테스트합니다.
  • 많은(대부분일 수도 있는) 공개 프로젝트는 최초의 기준 기능 릴리스가 이미 게시된 후에야 테스트 매트릭스에 새 릴리스 시리즈를 추가하며, 이로 인해 기본 동작이 변경된 후 이전 동작을 명시적으로 선택하도록 새로운 플래그 또는 API를 제공해야 하는 문제를 해결하기 어려울 수 있습니다.
  • 알려진 대상 환경이 있는 비공개 프로젝트는 실제로 사용 중인 마이크로 릴리스 버전에 대해 테스트합니다.
  • 대부분의 비공개 프로젝트 역시 최초의 기준 기능 릴리스가 이미 게시된 후에야 새 릴리스 시리즈로의 마이그레이션을 고려하며, 문제를 해결하려면 API 추가가 필요한 경우 다시 문제가 발생합니다.

이 PEP의 제안에 대한 핵심 동기는 위에서 설명한 공개 및 비공개 프로젝트 동작이 새로운 기대 사항이 아니라는 점입니다. 이는 오늘날 더 넓은 커뮤니티가 이미 CPython 릴리스 시리즈를 처리하는 방식을 설명한 것입니다. 따라서 이 PEP는 더 넓은 커뮤니티가 이미 이를 처리하는 방식에 맞도록 릴리스 정책과 프로세스를 조정하려는 시도이며, 그 반대로 더 넓은 커뮤니티가 우리에게 맞추도록 프로세스를 변경하려는 것이 아닙니다.

점진적 기능 릴리스

점진적 기능 릴리스는 이 PEP에서 제안하는 핵심적인 새 프로세스 추가 사항입니다. 점진적 기능 릴리스에는 기존 유지 관리 릴리스와 동일한 엄격한 런타임 호환성 요구 사항이 적용되지만, API 추가 및 개선에 대해서는 다음과 같이 더 완화된 정책이 적용됩니다.

  • 모든 표준 라이브러리 모듈(내장 기능 포함)에 새로운 공개 API를 추가할 수 있습니다.
  • 아래의 기능 감지 요구 사항을 충족하는 경우, 기존 API(내장 기능 포함)에 새로운 선택적 인자를 추가할 수 있습니다.
  • 적절한 버전 가드를 사용하면 안정적인 C ABI에 새로운 공개 API를 추가할 수 있습니다.
  • CPython C API에 새로운 공개 API를 추가할 수 있습니다.
  • 릴리스 관리자의 승인을 받으면 기존 API와 구문 구성 요소에 하위 호환성 있는 신뢰성 개선을 적용할 수 있습니다.
  • 릴리스 관리자의 승인을 받으면 기존 API와 구문 구성 요소에 성능 개선을 통합할 수 있습니다.

이 정책 변경의 목적은 사용자가 다음 기능 릴리스 시리즈를 기다린 후 업그레이드하는 데 따르는 본질적인 지연과 비용을 부담하도록 요구하는 대신, 새로운(그리고 기존의!) 언어 기능에 대한 사용성 개선을 더 신속하게 제공하는 것입니다.

또한 다음 기준 기능 릴리스에 기능을 추가하는 승인을 현재 릴리스 시리즈의 다음 점진적 기능 릴리스에서 해당 기능을 제공할지 여부와 별도로 검토할 수 있도록 설계되었습니다. 이에 따라 첫 번째 작업은 자원 봉사 기여자가 완료하고, 후속 작업은 유급 기여자가 처리할 수 있습니다(예를 들어 상용 Python 재배포자의 고객이 해당 공급업체에 기능을 백포트해 달라고 요청하거나, 핵심 개발자가 계약에 따라 특정 백포트를 수행하겠다고 제안할 수 있습니다). (이런 방식으로 버그 수정을 제한하는 데에는 잠재적인 윤리적 우려가 있지만, 새로운 기능의 백포트에는 그러한 우려가 적용되지 않습니다.)

점진적 기능 릴리스의 핵심 특성:

  • 점진적 기능 릴리스에서는 sys.version_info.feature_complete == False입니다.
  • 점진적 기능 릴리스에서는 sys.version_info.micro != 0입니다.
  • 점진적 기능 릴리스에서 이루어지는 모든 API 추가는 sys.version_info나 런타임 코드 객체 인트로스펙션에 의존하지 않는 효율적인 런타임 기능 감지를 지원해야 합니다. 대부분의 경우 영향을 받는 모듈에 간단한 hasattr 검사를 수행하면 이 목적을 달성할 수 있지만, 그렇지 않은 경우에는 기능 추가의 일부로 대체 접근 방식을 구현해야 합니다. 이 영역의 선행 사례로는 pickle.HIGHEST_PROTOCOL 특성, hashlib.algorithms_available 집합, 그리고 os 모듈이 이미 플랫폼 종속 기능 감지를 위해 제공하는 다양한 os.supports_* 집합이 있습니다.
  • 혼합 버전 환경에서 pickle 호환성을 유지하고 동일한 릴리스 시리즈 내 여러 API 버전 간 호환성 테스트를 더 쉽게 수행할 수 있도록, 점진적 기능 릴리스에서 이루어지는 모든 API 추가는 다음 절에 설명된 새로운 sys.feature_limit 설정을 지원해야 합니다.

점진적 기능 릴리스에 대한 핵심 기대 사항:

  • 변경 사항 포함 정책이 더 허용적으로 바뀌더라도, 모든 마이크로 릴리스에서는 “업그레이드 시 기존 설치를 중단하지 않는다”는 원칙이 여전히 핵심 요구 사항입니다.
  • 더 큰 영향을 미치는 변경 사항은 여전히 다음 기준 기능 릴리스로 연기해야 합니다.
  • 점진적 기능 릴리스에서 추가된 기능에 의존하기 시작하는 공개 Python 프로젝트는 Python-Requires 메타데이터를 적절하게 설정해야 합니다(프로젝트는 필요한 경우 이미 이렇게 하고 있습니다. 예를 들어 이전 버전의 asyncio.get_event_loop() 관련 문제로 인해 aiohttp는 구체적으로 3.5.3 이상을 요구합니다).

일부 표준 라이브러리 모듈은 점진적 기능 릴리스에서 허용되는 변경 사항에 자체적인 제한을 둘 수도 있습니다(예를 들어 새로운 해시 알고리즘은 기준 기능 릴리스에서만 hashlib.algorithms_guaranteed에 추가해야 하며, 점진적 기능 릴리스에서는 hashlib.algorithms_available에 알고리즘을 추가하는 것만 허용됩니다).

점진적 기능 릴리스 전반의 상호 운용성 유지

서로 다른 Python 버전에서 실행되는 Python 프로세스 간에 정보를 교환하기 위해 Python의 pickle 모듈을 사용하는 것은 일반적인 관행입니다. 릴리스 시리즈 간에는 이 호환성이 한 방향으로만 작동할 것으로 예상됩니다(즉, 사용 중단된 API를 제외하면 Python “X.Y+1” 프로세스는 Python “X.Y” 프로세스가 생성한 pickle 아카이브를 읽을 수 있어야 하지만, 그 반대는 성립하지 않습니다. 최신 아카이브가 이전 버전에 존재하지 않는 특성과 매개변수를 참조할 수 있기 때문입니다).

그러나 하나의 릴리스 시리즈 내에서는 양방향으로 성립할 것으로 예상됩니다. “새로운 기능 없음” 정책에 따라 Python “X.Y.Z+1”에서 생성된 거의 모든 pickle 아카이브를 Python “X.Y.Z” 프로세스가 읽을 수 있기 때문입니다.

이와 마찬가지로 Python 라이브러리와 애플리케이션은 릴리스 시리즈의 최신 버전에 대해서만 테스트되는 경우가 많으며, 이는 일반적으로 동일한 시리즈의 이전 릴리스에서도 코드가 계속 작동하도록 하기에 충분합니다.

나중의 “X.Y.Z” 릴리스에서 기능을 추가하고 이를 끌 방법을 제공하지 않으면 이러한 일반적인 관행에 문제가 발생합니다. “X.Y.Z” 버전의 CPython에서 테스트했을 때는 정상적으로 작동하는 라이브러리나 애플리케이션이 “X.Y.Z”에서 새로 도입된 기능을 사용하면 이전 버전에서 실패할 수 있으며, 해당 라이브러리나 애플리케이션이 이러한 새 인터페이스에 의존하여 생성한 pickle 아카이브도 이전 버전에서 읽히지 않을 수 있기 때문입니다.

이러한 문제를 해결하는 데 도움이 되도록, sys.version_info의 처음 3개 필드(major, minor, micro)에 대응하는 구조화된 시퀀스로서 새로운 sys.feature_limit 특성을 추가합니다.

새로운 CLI 옵션 (--feature-limit X.Y.Z)과 환경 변수 (PYTHONFEATURELIMIT=X.Y.Z)를 사용하여 이 속성을 설정합니다. PyCoreConfig 구조체에도 새로운 필드가 추가됩니다.:

wchar_t *feature_limit;

제한을 명시적으로 설정하지 않으면 sys.version_info의 처음 3개 필드가 기본값으로 사용됩니다. 제한을 sys.version_info[:2]의 하한과 sys.version_info[:3]의 상한 범위 밖의 값으로 설정하면, 필요한 경우 0으로 채운 뒤 해당 하한 또는 상한으로 고정됩니다.

예를 들어 현재 버전이 “3.9.3”인 경우, 명목상 제한은 다음과 같이 런타임 sys.feature_limit 값으로 변환됩니다.:

3 => (3, 9, 0)
3.8.1 => (3, 9, 0)
3.9 => (3, 9, 0)
3.9.2 => (3, 9, 2)
<unset> => (3, 9, 3)
3.9.3 => (3, 9, 3)
3.9.4 => (3, 9, 3)
4 => (3, 9, 3)

증분 기능 릴리스로 백포트된 새로운 API에는 기능 제한이 너무 낮을 경우 해당 API를 모듈에서 삭제하는 가드가 포함될 것으로 예상됩니다.:

def feature_api():
    ...

_version_feature_api_added = (3, 9, 1)
if _version_feature_api_added > sys.feature_limit:
    del feature_api

마찬가지로 새로운 매개변수에는 함수 시그니처를 이전 버전에 맞게 조정하는 가드가 포함될 것으로 예상됩니다.:

def feature_api(old_param1, old_param2, new_param=default):
    """Updated API docstring"""
    ...

_version_feature_api_changed = (3, 9, 1)
if _version_feature_api_changed > sys.feature_limit:
    _new_feature_api = feature_api
    def feature_api(old_param1, old_param2):
        """Legacy API docstring"""
        return _new_feature_api(old_param1, old_param2)

이러한 방식으로 가드를 구성하면 주 개발 브랜치와 백포트 브랜치 간 코드 구조를 가능한 한 유사하게 유지할 수 있으므로, 향후 버그 수정 사항을 계속 자동으로 백포트할 수 있습니다.

이러한 백포트된 API가 적절하게 보호되는지 확인하는 데 도움이 되도록 편의 함수 및/또는 추가 자동화 테스트가 결국 추가될 것으로 예상되지만, 가상의 예만을 바탕으로 해당 API와 자동화 테스트를 설계하기보다는 구체적인 실제 예가 제공되어 설계를 이끌 수 있을 때까지 기다리는 것이 합리적으로 보입니다.

기능 완성 릴리스 및 이후 유지보수 릴리스

특정 기능 릴리스 시리즈의 기능 완성 릴리스는 증분 기능 릴리스에 대한 일반 정책에 따라 개발되지만, 한 가지 구별되는 특징을 갖습니다.

  • 기능 완성 릴리스에서는 sys.version_info.feature_complete == True입니다.

이후의 모든 유지보수 및 보안 수정 전용 릴리스에도 해당 플래그가 설정되며, 이러한 릴리스는 비공식적으로 “기능 완성 릴리스”라고 부를 수 있습니다. 그러나 릴리스 시리즈 정의의 관점에서는 해당 플래그를 “True”로 설정하는 최초의 릴리스가 기능 완성 릴리스입니다.

잠정 API에 대한 정책 조정안

잠정 API 관리의 일관성을 높이기 위해 이 PEP에서는 특정 릴리스 시리즈의 기능 완성 릴리스 이후 잠정 API에도 일반적인 하위 호환성 요구 사항을 적용할 것을 제안합니다.

잠정 API 관리의 다른 측면은 현재와 동일하게 유지되므로, API가 잠정 상태로 남아 있는 한 기준 릴리스와 증분 기능 릴리스에서는 해당 API에 일반적인 하위 호환성 요구 사항이 적용되지 않습니다.

다음은 3.0.0 이후 CPython의 마이크로 릴리스에서 문서화된 API 추가 및 변경 사항을 분석한 결과이며, 이 정책은 최종 사용자에게 더 높은 명확성을 제공할 것으로 예상됩니다(기능 완성 릴리스에서는 잠정 API도 해당 릴리스 시리즈에서 안정화되기 때문입니다). 표준 라이브러리 유지 관리자에게 실질적인 단점은 최소화됩니다.

  • 21 3.x.1 버전 추가/변경 참고 사항
  • 30 3.x.2 버전 추가/변경 참고 사항
  • 18 3.x.3 버전 추가/변경 참고 사항
  • 11 3.x.4 버전 추가/변경 참고 사항
  • 1 3.x.5 버전 추가/변경 참고 사항
  • 0 3.x.6+ 버전 추가/변경 참고 사항

기준 릴리스 이후 변경이 필요한 경우, 대부분의 변경은 최초 두 번의 유지보수 릴리스 내에 발생하며, 이 릴리스들은 항상 기준 릴리스 후 12개월 이내에 이루어졌습니다.

(참고: 이러한 수치는 잠정 API에만 해당하는 것이 아니며, 기준 릴리스 이후 의미적 변경이 이루어져 문서에서 다룰 필요가 있다고 판단된 모든 API를 포함합니다. 변경 사항을 중복 집계하지 않기 위해 이 숫자에서는 What’s New 섹션의 변경 표시는 제외합니다)

동기

이 PEP에서 변경을 제안하는 동기는 본질적으로 PEP 596에서 변경을 제안한 동기와 동일합니다. 기능 릴리스 사이의 현재 18~24개월 간격은 특히 표준 라이브러리에 많은 바람직하지 않은 결과를 초래합니다(자세한 내용은 PEP 596을 참조하십시오).

이 PEP가 PEP 596의 구체적인 제안에 대해 우려하는 점은 이 제안이 적극적으로 지원되는 Python 브랜치의 수를 두 배로 늘려 Python 커뮤니티 전체의 호환성 테스트 매트릭스를 복잡하게 만들고, 안정 ABI를 사용하지 않을 때 PyPI에 업로드해야 하는 바이너리 Python 휠의 수를 늘리며, 전반적으로 Python 생태계 전체에 상당한 추가 비용을 초래할 가능성이 높다는 것입니다.

이 PEP에서 취하는 관점은 관련 비용을 실제로 발생시키지 않고 더 빠른 기능 릴리스의 이점 대부분을 제공하는 대안적 접근 방식이 있다는 것입니다. 현재 X.Y.0 “기능 동결”을 두 부분으로 나누어, 기준 X.Y.0 릴리스에서는 “런타임 호환성 동결”만 적용하고 전체 표준 라이브러리 기능 동결은 릴리스 시리즈 수명 주기의 이후 시점까지 연기할 수 있습니다.

주의 사항 및 제한 사항

이 제안은 Python 3.8에 소급하여 적용되지 않으며, Python 3.9 및 이후 릴리스만을 대상으로 제안됩니다.

실제 릴리스 날짜는 릴리스 관리자가 릴리스 팀의 가용성과 기타 행사(예: PyCon US 또는 연례 핵심 개발 스프린트)의 일정에 따라 재량으로 최대 한 달 앞이나 뒤로 조정할 수 있습니다. 그러나 이 제안의 목표 중 하나는 기여자와 최종 사용자 모두에게 일관된 연간 주기를 제공하는 것이므로, 조정은 이상적으로 드물어야 합니다.

이 PEP는 릴리스 시리즈 내 마이크로 릴리스의 구체적인 주기를 규정하지 않으며, 릴리스 시리즈 수명 주기 단계(프리 알파, 알파, 베타, 기능 릴리스, 버그 수정, 보안 수정) 간 전환을 위한 대략적인 일정만 지정합니다. 각 단계 내 마이크로 릴리스의 수는 해당 시리즈의 릴리스 관리자가 자신과 해당 시리즈의 나머지 릴리스 팀이 관련 작업을 수행할 준비가 되는 빈도를 바탕으로 결정합니다.

그러나 예시 일정을 위해 이 PEP는 분기별 마이크로 릴리스를 가정합니다(이는 Python 3.6 및 3.7에서 사용된 주기로, 일부 과거 릴리스 시리즈에서 사용된 연 2회 주기와 Python 3.8 및 3.9에서 계획된 월별 주기의 중간에 해당합니다).

설계 논의

더 빈번하게 기준 기능 릴리스를 진행하는 대신 이 제안을 채택하는 이유는 무엇입니까?

기준 기능 릴리스에 수반되는 파일 시스템 레이아웃 변경 및 기타 본질적으로 호환되지 않는 변경은 더 광범위한 Python 커뮤니티의 많은 부분에 추가 작업을 발생시킵니다.

이러한 레이아웃 변경을 Python 버전 번호 지정 체계에서 분리하는 것 자체도 하위 호환성이 없는 변경을 수반하며, 어떤 버전들이 서로 덮어써서 설치될 수 있고 단일 시스템에 어떤 버전들을 병렬로 설치할 수 있는지에 대한 커뮤니티의 기대도 조정해야 합니다.

또한 “X.Y+1이 출시될 때까지 Python 버전 X.Y만 지원하고, X.Z는 X.Z+2가 출시될 때까지 지원한다”와 같은 지원 기간의 차이를 커뮤니티에 전달할 간단한 방법도 없습니다.

따라서 이 PEP는 대다수의 Python 사용자가 릴리스 정책을 변경한다는 사실에 단지 신경 쓸 필요가 없어야 한다는 것을 출발점으로 삼으며, 영향을 받아야 하는 사람들은 표준 라이브러리 개선 사항(및 기타 하위 호환 인터프리터 개선 사항)을 간절히 기다리는 사용자와 복잡한 배포 환경에서 업무상 중요한 애플리케이션을 관리해야 하는 사용자뿐입니다.

Python 라이브러리 개발에 대한 영향

많은 Python 라이브러리(오픈 소스와 독점 소프트웨어 모두)는 현재 프로젝트가 여전히 지원하는 각 기능 릴리스 시리즈 내 최신 마이크로 릴리스만을 대상으로 테스트하는 관행을 채택하고 있습니다.

이 PEP의 설계 가정은 릴리스 시리즈의 기능 릴리스 단계에서도 이 관행이 계속된다는 것이며, 기능이 완성되기 전에 새 릴리스 시리즈를 채택하는 사용자는 증분 기능 릴리스를 면밀히 추적할 것으로 예상합니다.

이전 기능 릴리스 시리즈를 지원하는 라이브러리는 증분 기능 릴리스에 추가된 기능을 채택할 가능성이 낮으며, 그러한 기능을 채택하는 경우 관련 폴백 호환성 전략은 해당 릴리스 시리즈의 이전 릴리스에서도 효과적으로 작동하도록 구현해야 합니다.

제안된 Scientific Python 생태계 지원 기간에 대한 영향

SciPy 2019에서의 논의를 바탕으로, 이전 Python 버전에 대한 지원 중단을 위한 Scientific Python 생태계 전반의 공통 규약을 정의하는 NEP가 현재 작성되고 있습니다 [2].

해당 정책의 정확한 표현은 아직 논의 중이지만, 최초 제안은 매우 단순했습니다. 지난 42개월 이내에 게시된 모든 Python 기능 릴리스를 지원하는 것입니다.

18개월의 기능 릴리스 주기에서는 최소한 가장 최근의 두 기능 릴리스를 항상 지원하고, X.(Y+2).0이 출시된 후 약 6개월이 지나면 모든 X.Y.z 릴리스에 대한 지원을 중단하게 됩니다. 이는 대략 격년으로 6개월 동안 가장 최근의 세 기능 릴리스를 지원한다는 의미입니다.

12개월의 릴리스 주기에서는 최소한 가장 최근의 세 기능 릴리스를 항상 지원하고, X.(Y+3).0이 출시된 후 약 6개월이 지나면 모든 X.Y.z 릴리스에 대한 지원을 중단하게 됩니다. 이는 매년 절반의 기간 동안 가장 최근의 네 기능 릴리스를 지원한다는 의미입니다.

24개월의 릴리스 주기에서는 42개월의 지원 주기에 따라 최소한 가장 최근의 기능 릴리스를 항상 지원하고, X.(Y+1).0이 출시된 후 약 18개월이 지나면 모든 X.Y.z 기능 릴리스에 대한 지원을 중단하게 됩니다. 이는 대략 격년으로 6개월 동안 하나의 기능 릴리스만 지원된다는 의미이며(이 기간은 X.(Y+2).0 기준 기능 릴리스의 사전 릴리스 테스트 기간과 겹칩니다).

이 PEP의 제안에서 중요한 점은 해당 지원 기간이 최신 릴리스 시리즈가 기능 완성 상태에 도달할 때까지 라이브러리 개발자가 이전 릴리스 시리즈에 대한 지원을 유지해야 한다는 권고를 따른다는 것입니다. 즉, 기준 기능 릴리스 후 18개월이 지나 지원을 중단하는 것은 시리즈를 기능 완성 상태로 만든 릴리스가 정확히 어떤 릴리스인지 추적하지 않아도 기능 완성 릴리스 후 6개월이 지나 지원을 중단하는 것과 대략 동등합니다.

단순한 배포 환경에 대한 영향

이 PEP에서 “단순한” 배포 환경은 모든 대상 환경을 동시에(또는 최소한 더 높은 수준의 애플리케이션 새 버전을 배포하기 전에) 새 Python 마이크로 버전으로 업데이트할 수 있고, 이전 Python 버전이 새 Python 버전으로 생성된 피클 스트림을 안정적으로 읽을 수 있어야 한다는 요구 사항이 없어서, 수행되는 모든 사전 릴리스 테스트가 단일 Python 마이크로 버전만 대상으로 하면 되는 모든 사용 사례를 의미합니다.

이러한 경우의 가장 단순한 예는 개인용 스크립팅이며, 여기서는 테스트 환경과 대상 환경이 정확히 동일한 환경입니다.

이와 마찬가지로 단순한 환경에는 컨테이너화된 웹 서비스가 해당합니다. 여기서는 배포에 사용되는 것과 동일한 Python 컨테이너를 CI 파이프라인에서도 사용하며, 대상 시스템에 이미 존재하는 Python 배포에 의존하지 않고 자체 Python 런타임을 포함하는 애플리케이션도 해당합니다.

이러한 사용 사례에서 이 PEP는 중요한 영향을 미치지 않아야 하며, 해당 버전이 기능 완성 상태인지 여부와 관계없이 단일 마이크로 버전만 테스트하면 됩니다.

복잡한 배포 환경에 대한 영향

이 PEP의 목적상, “복잡한” 배포 환경은 위의 “단순한 배포” 기준을 충족하지 않는 사용 사례입니다. 즉, 배포 프로세스의 일부로 새 애플리케이션 버전이 동일한 릴리스 시리즈 내의 서로 다른 두 개 이상의 마이크로 버전과 결합되며, 항상 한 번에 정확히 하나의 마이크로 버전만을 대상으로 하지는 않습니다.

이 PEP의 제안이 기능 제공 지연 시간을 줄이는 바람직한 효과를 낸다면, 아직 기능 완성 상태에 도달하지 않은 릴리스 시리즈를 사용하는 개발자는 새 기능이 제공되는 즉시 실제로 이를 사용하게 될 것으로 예상할 수 있습니다. 따라서 더 새로운 증분 기능 릴리스에 대해 테스트하는 것은, 더 새로운 유지보수 릴리스에 대해 테스트하는 것이 이전 유지보수 릴리스에 대한 호환성 테스트로서 갖는 타당성보다도, 기준 기능 릴리스 및 이전 증분 기능 릴리스와의 호환성을 검증하는 테스트로서의 타당성이 더욱 낮아집니다.

이러한 경우를 처리하는 한 가지 방법은 시리즈가 “기능 완성” 상태에 도달할 때까지 새 Python 버전의 사용을 단순히 금지하는 것입니다. 이러한 정책은 새 기능 릴리스 시리즈에 관한 한 이미 많은 조직에서 사실상 채택하고 있으며, 최초 릴리스 후 수개월 또는 수년이 지나서야 운영 환경에 수용되고 있습니다. 이 정책을 채택하면 이러한 조직은 2년에 한 번씩 새 Python 버전을 여전히 도입할 가능성이 있습니다. 다만 이는 기준 기능 릴리스가 아니라 기능 완성 릴리스의 가용성을 바탕으로 하게 됩니다.

전면적인 금지보다 덜 엄격한 대안은 제안된 PYTHONFEATURELIMIT 설정을 사용하여 새로운 증분 기능 릴리스로 단계적 마이그레이션을 활성화하는 것입니다:

  • 처음에는 CI와 배포 환경에서 PYTHONFEATURELIMIT=X.Y.0을 설정한 상태로 Python X.Y.0을 배포합니다.
  • PYTHONFEATURELIMIT=X.Y.0 설정을 유지하면서 Python X.Y.1을 CI에 배포합니다.
  • CI 결과가 성공하면 Python X.Y.1을 프로덕션에 배포합니다.
  • 배포 환경을 업데이트하여 PYTHONFEATURELIMIT=X.Y.1로 설정하도록 합니다.
  • 모든 배포 환경이 업데이트된 후에만 CI에서 PYTHONFEATURELIMIT=X.Y.1을 설정합니다.
  • 릴리스 시리즈의 기능 완성 릴리스를 포함하여 그때까지의 각각의 새 릴리스에 대해 이 프로세스를 반복합니다.
  • 시리즈가 기능 완성 상태가 되면, 일관성을 위해 이와 동일한 프로세스를 계속 진행하거나, 아니면 PYTHONFEATURELIMIT 업데이트를 중단하고 기능 완성 버전 번호로 유지합니다.

기능 추가 기간

이 PEP는 초기 기준 기능 릴리스 이후 12개월로 기능 추가를 제한할 것을 제안합니다.

그 주된 동기는 특히 Ubuntu LTS 일정에 맞추기 위한 것입니다. 이에 따라 Python 3.9.x 시리즈의 기능 완성 릴리스가 2021년 10월에 게시되어 Ubuntu 22.04 릴리스에 포함될 준비를 갖추게 됩니다. (RHEL, SLES, Debian과 같은 다른 LTS Linux 배포판은 고정된 게시 주기가 없으므로 입력의 안정 버전에 맞추기 위해 LTS 일정을 조금 더 쉽게 조정할 수 있습니다. Canonical은 의도적으로 자체 릴리스 주기에서는 그러한 유연성을 부여하지 않았습니다).

이에 따라 12개월의 기능 추가 기간은 Python 3.8.0의 2019년 10월 릴리스부터 2021년 10월의 최종 Python 3.9.x 증분 기능 릴리스까지의 기간을 프리릴리스 개발과 그 이후의 증분 기능 릴리스 사이에 균등하게 나눈 결과로 정해집니다.

이 부분에서는 이 PEP가 PEP 596의 제안 일부를 채택하여, 그 기간을 프리릴리스 개발 약 9개월과 증분 기능 릴리스 약 15개월로 나눌 수도 있습니다:

  • 2019-11: 3.9.0a1
  • … 릴리스 관리자가 결정하는 추가 알파 릴리스
  • 2020-03: 3.9.0b1
  • 2020-04: 3.9.0b2
  • 2020-05: 3.9.0b3 (ABI 호환성을 고정하는 최종 베타 릴리스)
  • 2020-06: 3.9.0rc1
  • … 릴리스 관리자가 결정하는 추가 릴리스 후보
  • 2020-07: 3.9.0 (BFR)
  • 2020-10: 3.9.1 (IFR)
  • 2021-01: 3.9.2 (IFR)
  • 2021-04: 3.9.3 (IFR)
  • 2021-07: 3.9.4 (IFR)
  • 2021-10: 3.9.5
  • 2022-01: 3.9.6
  • 2022-04: 3.9.7
  • 2022-07: 3.9.8
  • 2022-10: 3.9.9 (최종 정기 유지보수 릴리스)
  • … 필요에 따라 추가 보안 수정 전용 릴리스
  • 2025-10: 3.9.x 브랜치 종료

이 접근 방식을 따르면 항상 2개 또는 3개의 활성 브랜치가 존재하게 되지만, “프리 알파”, “프리 베타”, “프리 릴리스” 단계와 비교할 때 브랜치가 “기능 릴리스” 단계에 있는 기간이 비례적으로 더 길어집니다.

  • 2019-04 -> 2019-10: 3.9.0 프리 알파, 3.8.0 프리 릴리스, 3.7.x 유지보수
  • 2019-10 -> 2020-03: 3.9.0 프리 베타, 3.8.x 유지보수
  • 2020-03 -> 2020-07: 3.10.0 프리 알파, 3.9.0 프리 릴리스, 3.8.x 유지보수
  • 2020-07 -> 2021-10: 3.10.0 프리 알파, 3.9.x 기능 릴리스, 3.8.x 유지보수
  • 2021-10 -> 2022-03: 3.10.0 프리 베타, 3.9.x 유지보수
  • 2022-03 -> 2022-07: 3.11.0 프리 알파, 3.10.0 프리 릴리스, 3.9.x 유지보수
  • 2022-07 -> 2023-10: 3.11.0 프리 알파, 3.10.x 기능 릴리스, 3.9.x 유지보수
  • 2023-10 -> 2024-03: 3.11.0 프리 베타, 3.10.x 유지보수
  • 2024-03 -> 2024-07: 3.12.0 프리 알파, 3.11.0 프리 릴리스, 3.10.x 유지보수
  • … 기타

릴리스되지 않은 프리 알파 기간

이 PEP의 기준 제안에서 제시하는 일정에는 메인 git 브랜치에서 릴리스를 만들지 않고 18개월을 보내는 기간이 여전히 포함되어 있습니다(예: 3.9.0b1은 2020-05에 분기되고 3.10.0a1은 2021-11까지 공개되지 않습니다). 다만 이 기간 중 12개월 동안 가장 최근의 유지보수 브랜치로 백포트할 수 있는 변경 사항의 범위를 더 넓힐 수 있습니다.

릴리스 시리즈 수명 주기에서 베타 브랜치 지점을 더 앞당기는 제안의 변형안은 직접 릴리스가 없는 기간을 21개월로 늘립니다. 메인 브랜치에서 직접 릴리스가 이루어지는 유일한 기간은 이전 릴리스 시리즈의 마지막 증분 기능 릴리스와 몇 달 뒤의 베타 브랜치 지점 사이의 비교적 짧은 기간이 됩니다.

연간 주기를 “대규모 기반 기능 개선”과 “위험이 낮고 API 사용성을 개선하는 대상 중심의 개선” 사이에서 교대로 운영하는 것은 이 제안의 의도적인 특징이지만, 이전 릴리스 시리즈가 분기된 직후에 변경 사항이 이루어지는 경우 그토록 오랫동안 피드백을 기다리는 것은 여전히 이상해 보입니다.

이를 처리하는 대안은 기능 추가 기간에 다음 기준 기능 릴리스의 알파 릴리스를 공개하기 시작하는 것입니다(PEP 596에서 Python 3.8.0 릴리스 후보 기간에 Python 3.9.0 알파 릴리스 공개를 시작할 것을 제안하는 방식과 유사합니다).

그러나 정책 수준에서 구체적인 일정을 정하는 대신, 관리 중인 릴리스에 제안된 구체적인 변경 사항을 바탕으로 그 결정을 개별 릴리스 관리자에게 맡기는 것이 합리적일 수 있습니다.

왜 완전한 시맨틱 버전 관리로 바로 전환하지 않습니까?

이것이 새로운 언어를 위한 버전 관리 설계 문서라면 시맨틱 버전 관리를 사용했을 것입니다. 위에서 설명한 기준 기능 릴리스 정책은 X.0.0 릴리스에 적용하고, 증분 기능 릴리스 정책은 X.Y.0 릴리스에 적용하며, 유지보수 릴리스 정책은 X.Y.Z 릴리스에 적용했을 것입니다.

특히 Python의 문제는 병렬 설치 지원 및 ABI 호환성 정의와 관련된 모든 정책과 속성이 현재 버전 번호의 첫 번째 두 필드에 연결되어 있으며, 이러한 방식이 거의 30년 동안 유지되어 왔다는 점입니다.

따라서 무엇보다 먼저 증분 기능 릴리스를 도입할지에 대한 정책 문제와 버전 번호 체계가 다양한 릴리스 유형의 의미에 더 잘 부합하도록 만드는 기술적 문제를 분리하는 것이 합리적입니다.

이 PEP의 제안이 Python 3.9에 대해 Steering Council의 승인을 받는다면, 그러한 기술적 문제를 다루기에 더 좋은 시점은 그 다음 2022년 10월 기준 기능 릴리스가 될 것입니다. “Python 4.0”(주 버전이 3 또는 그 이상인지가 아니라 정확히 3인지 잘못 확인하는 코드)이나 “Python 3.10”(부 버전이 항상 소수점 이하 한 자리만 포함한다고 잘못 가정하는 코드)을 선택하는 데에는 이미 본질적인 호환성 위험이 존재하기 때문입니다 [1].

이 PEP의 본문은 2022년에 공개되는 릴리스가 3.10일 것이라고 가정하지만(PEP 작성자는 개인적으로 이것이 더 합리적이고 가능성이 높은 선택이라고 판단합니다), 그 결정에는 양쪽 모두 복잡한 장단점이 있습니다. 또한 이 PEP는 “Python 4.0” 옵션을 선택하는 데 잠재적인 장점을 추가한다고 볼 수 있습니다(단, 영향을 받는 설치 레이아웃과 호환성 마커를 주 버전과 부 버전 모두가 아니라 주 버전 번호만 고려하도록 수정해야 한다는 단서가 있습니다).

이러한 버전 번호 변경이 제안되어 승인된다면, 위에서 제시한 3.10.x 일정 예시는 다음과 같은 4.x 시리즈 일정으로 바뀌게 됩니다:

  • 2021-11: 4.0.0a1
  • … 릴리스 관리자가 결정하는 추가 알파 릴리스
  • 2022-05: 4.0.0b1
  • … 릴리스 관리자가 결정하는 추가 베타 릴리스
  • 2022-08: 4.0.0bX (ABI 호환성을 고정하는 최종 베타 릴리스)
  • 2022-09: 4.0.0rc1
  • … 릴리스 관리자가 결정하는 추가 릴리스 후보
  • 2022-10: 4.0.0 (BFR)
  • 2023-01: 4.1.0 (IFR)
  • 2023-04: 4.2.0 (IFR)
  • 2023-07: 4.3.0 (IFR)
  • 2023-10: 4.4.0 (IFR)
  • 2024-01: 4.4.1
  • 2024-04: 4.4.2
  • 2024-07: 4.4.3
  • 2024-10: 4.4.4 (최종 정기 유지보수 릴리스)
  • … 필요에 따른 추가 보안 수정 전용 릴리스
  • 2027-10: 4.x 브랜치 종료

그리고 5년 일정 예측은 다음과 같을 것입니다.

  • 2019-04 -> 2019-10: 3.9.0 사전 알파, 3.8.0 사전 릴리스, 3.7.x 유지보수
  • 2019-10 -> 2020-05: 3.9.0 사전 베타, 3.8.x 유지보수
  • 2020-05 -> 2020-10: 4.0.0 사전 알파, 3.9.0 사전 릴리스, 3.8.x 유지보수
  • 2020-10 -> 2021-10: 4.0.0 사전 알파, 3.9.x 기능 릴리스, 3.8.x 유지보수
  • 2021-10 -> 2022-05: 4.0.0 사전 베타, 3.9.x 유지보수
  • 2022-05 -> 2022-10: 5.0.0 사전 알파, 4.0.0 사전 릴리스, 3.9.x 유지보수
  • 2022-10 -> 2023-10: 5.0.0 사전 알파, 4.x.0 기능 릴리스, 3.9.x 유지보수
  • 2023-10 -> 2024-05: 5.0.0 사전 베타, 4.x.y 유지보수
  • 2024-05 -> 2024-10: 6.0.0 사전 알파, 5.0.0 사전 릴리스, 4.x.y 유지보수
  • … 기타

참고 자료