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

Python 개선 제안 한국어 번역

PEP 602 – Python의 연간 릴리스 주기

Author:
Łukasz Langa <lukasz at python.org>
PEP-Delegate:
Brett Cannon <brett at python.org>
Discussions-To:
Discourse thread
Status:
Active
Type:
Process
Created:
04-Jun-2019
Python-Version:
3.9
Post-History:
09-Oct-2023
Resolution:
Python-Dev thread
Table of Contents

번역·라이선스 안내

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

초록

이 문서는 Python 3.9부터 적용되는 Python 릴리스 일정의 변경 사항을 설명합니다. 이 변경으로 릴리스 주기가 빨라져 기능 버전이 12개월마다, 즉 매년 10월에 예측 가능하게 릴리스됩니다.

구현

기능 버전 개발에 17개월

이 PEP는 Python 3.X.0이 약 17개월 동안 개발된다고 제안합니다.

  • 처음 five months는 Python 3.(X-1).0의 베타 및 릴리스 후보 단계와 겹치므로 버전이 지정되지 않습니다.
  • 다음 seven months는 버전이 지정된 알파 릴리스에 사용되며, 이 기간에는 새로운 기능이 점진적으로 추가되고 버그 수정도 포함됩니다.
  • 이어지는 three months는 버전이 지정된 네 번의 베타 릴리스에 사용되며, no new features를 추가할 수 없지만 버그 수정은 계속 포함됩니다.
  • 마지막 two months는 두 번의 릴리스 후보(필요한 경우 그 이상)에 사용되며 Python 3.X.0의 최종 릴리스가 출시되면서 마무리됩니다.

2년간의 전면 지원, 추가 3년간의 보안 수정

Python 3.X.0이 릴리스된 후 3.X 시리즈는 5년 동안 유지 관리됩니다.

  • first twenty four months (2년) 동안 버그 수정 업데이트를 받고, 정식 릴리스(Windows 및 macOS용 소스와 설치 프로그램)가 대략 격월로 이루어집니다.
  • 다음 thirty six months (3년) 동안 보안 업데이트를 받고, 필요에 따라 소스 전용 릴리스가 이루어집니다(고정된 주기 없음).
  • 마지막 소스 전용 릴리스는 3.X.0 후 five years가 지나면 이루어집니다.

참고: 2년간의 전면 지원은 Python 3.13부터 시작합니다. Python 버전 3.9 - 3.12는 1½년간의 전면 지원에 이어 3½년간 추가 보안 수정이 제공되는 일정으로 운영됩니다.

연간 릴리스 주기

Python 3.(X+1).0의 기능 개발은 Python 3.X.0 베타 1이 릴리스되는 즉시 시작됩니다. 이에 따라 Python 기능 버전 간에 12개월의 시차가 생깁니다.

예

  • 3.9 개발 시작: 2019년 6월 4일 화요일
  • 3.9.0 알파 1: 2019년 10월 14일 월요일
  • 3.9.0 알파 2: 2019년 11월 18일 월요일
  • 3.9.0 알파 3: 2019년 12월 16일 월요일
  • 3.9.0 알파 4: 2020년 1월 13일 월요일
  • 3.9.0 알파 5: 2020년 2월 17일 월요일
  • 3.9.0 알파 6: 2020년 3월 16일 월요일
  • 3.9.0 알파 7: 2020년 4월 13일 월요일
  • 3.9.0 베타 1: 2020년 5월 18일 월요일 (이 시점 이후에는 새로운 기능이 없습니다.)
  • 3.9.0 베타 2: 2020년 6월 8일 월요일
  • 3.9.0 베타 3: 월요일, 2020-06-29
  • 3.9.0 베타 4: 월요일, 2020-07-20
  • 3.9.0 후보 1: 월요일, 2020-08-10
  • 3.9.0 후보 2: 월요일, 2020-09-14
  • 3.9.0 최종: 월요일, 2020-10-05
../_images/pep-0602-example-release-calendar.png

Figure 1. Consequences of the annual release cycle on the calendar.

이에 비해 이 PEP가 거부되고 Python이 현재 릴리스 일정을 유지한다면 다음과 같습니다.

  • 3.9 개발 시작: 화요일, 2019-06-04
  • 3.9.0 알파 1: 월요일, 2020-08-03 (10개월 후)
  • 3.9.0 알파 2: 월요일, 2020-09-07
  • 3.9.0 알파 3: 월요일, 2020-10-05
  • 3.9.0 알파 4: 월요일, 2020-11-02
  • 3.9.0 베타 1: 월요일, 2020-11-30 (6개월 후)
  • 3.9.0 베타 2: 월요일, 2021-01-04
  • 3.9.0 베타 3: 월요일, 2021-02-01
  • 3.9.0 베타 4: 월요일, 2021-03-01
  • 3.9.0 후보 1: 월요일, 2021-03-29
  • 3.9.0 후보 2: 월요일, 2021-04-05 (필요한 경우)
  • 3.9.0 최종: 월요일, 2021-04-19 (6개월 후)

관련 정책

사용 중단 예정

호환성을 깨뜨리는 변경에 관한 현재 정책은 사용 중단 예정 기능을 Python에서 제거하거나 __future__ 동작을 기본적으로 활성화하기 전에 최소 두 번의 릴리스를 거친다고 가정합니다. 이는 PEP 387에 문서화되어 있습니다.

이 PEP는 호환성을 깨뜨리는 변경을 적용하기 전에 최소 두 번의 릴리스를 거치는 이 정책을 유지할 것을 제안합니다.

운영 위원회의 임기

현재 PEP 13의 문구는 “각 기능 릴리스 후에 새로운 위원회가 선출됩니다”라고 명시합니다. 이 PEP는 일관된 선출 일정을 유지할 수 있으므로 이 정책을 유지할 것을 제안합니다.

릴리스 관리자의 임기

현재 문서화되지 않은 관례는 한 명의 릴리스 관리자가 Python의 두 번의 기능 릴리스를 담당하는 것입니다. 이 PEP는 이 정책을 유지하되, 운영 위원회와 릴리스 관리자 협의체의 승인을 받아 임기를 더 많은 릴리스까지 연장할 수 있도록 할 것을 제안합니다.

특히 이 PEP는 현직 릴리스 관리자가 작성했으며 그 효과로 릴리스 관리자의 임기가 짧아지게 되므로, 작성자는 이러한 혼란을 보상하기 위해 세 번째 기능 릴리스의 릴리스를 관리하는 방안에도 열려 있습니다.

근거 및 목표

이 변경은 다음과 같은 이점을 제공합니다.

  • 릴리스 규모를 줄입니다. 릴리스 주기를 두 배로 늘린다고 해서 사용 가능한 개발 리소스가 두 배가 되지는 않으므로, 연속되는 릴리스는 기능 측면에서 더 작아집니다;
  • 기능과 버그 수정이 더 빨리 사용자에게 제공됩니다;
  • 단일 릴리스에서 변경되는 범위를 줄여 사용자에게 더 점진적인 업그레이드 경로를 제공합니다;
  • 릴리스 일정을 예측 가능하게 만듭니다. 최종 릴리스는 항상 10월에 이루어지고(연례 핵심 개발 스프린트 이후이므로), 베타 단계는 5월 말에 시작됩니다(PyCon US 스프린트 이후이므로). 이는 일정에 Python 관련 활동을 포함할 계획을 세워야 하는 핵심 개발자에게 특히 중요합니다;
  • 기능이 “18개월 동안 지연될” 위험 때문에 “Beta 1” 직전에 기능을 서둘러 추가하려는 압박을 줄입니다;
  • Python 릴리스 관리 일정과 Fedora 같은 외부 배포자의 일정을 동기화할 수 있습니다. 이러한 배포자들은 역사적으로 핵심 Python뿐 아니라 서드파티 라이브러리에서도 회귀를 조기에 발견하는 데 매우 큰 도움을 주었으며, 커뮤니티가 출시 첫날부터 최신 Python 버전을 지원하도록 발전하는 데 기여해 왔습니다;
  • 명시적인 알파 릴리스 단계를 늘려 새 기능의 진행 상황을 의미 있게 확인할 수 있는 시점을 제공합니다;
  • 암묵적인 “alpha 0” 릴리스 단계를 크게 줄입니다. 이 단계는 어차피 새 개발에 제한적으로만 유용하며(현재 개발 중인아직 출시되지 않은 버전의 베타 단계와 겹칩니다).

목표가 아닌 사항

연례 릴리스 일정을 채택하면 달력 버전 관리로 자연스럽게 전환할 수 있습니다. 예를 들어 Python 3.9를 10월 ‘20에 출시되었다는 이유로 “Python 3.20”이라고 부르는 식이며, 같은 방식으로 “Python 3.23”은 10월 ‘23에 출시되는 버전이 됩니다.

달력 버전 관리로 쉽게 전환할 수 있다는 점을 연례 릴리스 주기의 장점으로 볼 수 있지만, 이 PEP는 Python의 버전 관리 방식을 변경하는 것을 지지하거나 반대하지 않습니다. 연례 릴리스 주기를 채택하게 되면 버전 관리 문제는 별도의 PEP에서 다룹니다.

위험이 아닌 사항

이 변경은 버그 수정 릴리스와 보안 수정 릴리스 모두를 포함하여, 현재 문서화된 Python 릴리스 지원 일정을 단축하지 않습니다.

이 변경은 개발 속도를 높이지 않습니다. Python이 더 빠르게 비호환 상태가 되거나 새로운 기능을 더 빠르게 축적하게 되는 것은 아닙니다. 단지 기능이 개발되는 대로 더 점진적으로 릴리스될 뿐입니다.

따라서 이 변경으로 사용자가 훨씬 더 빠르게 업그레이드할 수 있게 되지만, 반드시 그렇게 해야 하는 것은 아닙니다. 예를 들어 두 번에 한 번씩 릴리스할 때마다 업그레이드한다면 Python 사용 경험은 현재 상황과 비슷할 것입니다.

위험

Python 재배포

이를 위해서는 Linux 배포판과 같은 통합자가 시스템 내에서 Python을 릴리스하는 방식에 대한 변경이 필요합니다.

테스트 매트릭스

결과적으로 현재 지원되는 모든 Python 버전을 지원하려는 라이브러리 및 애플리케이션 유지 관리자의 테스트 매트릭스가 한두 개 증가합니다:

../_images/pep-0602-overlapping-support-matrix.png

Figure 2. Testing matrix in the 18-month cadence vs. the 12-month

현재 릴리스 주기의 “릴리스 관리자의 재량에 따른 버그 수정 지원 연장” 단계는 명문화되어 있지 않습니다. 실제로 PEP 101은 현재 Python 3.(X+1).0이 릴리스된 후에는 Python 3.X.0에 대해 마지막 버그 수정 릴리스 하나만 이루어진다고 명시합니다. 그러나 실제로는 Python 3의 최소 최근 네 버전이 약 6개월 동안 다음 버전의 안정 릴리스와 겹쳤습니다. 그림 2에는 이 정보가 포함되어 있어, 12개월 릴리스 주기에서 안정 버전 릴리스 간의 중복이 전혀 새로운 일이 아님을 보여 줍니다.

다른 정책은 릴리스 주기에 따라 달라질 수 있습니다

이전 절에서 식별된 종속 정책을 다루었지만, Python 릴리스 시점에 암묵적으로 의존하는 다른 영역이 있을 가능성도 충분합니다.

거부된 아이디어

현재의 18개월 릴리스 주기를 유지하십시오.

이는 핵심 개발자와 최종 사용자 모두에게 바람직하지 않습니다. 핵심 개발자의 관점에서 보면:

  • 매년 릴리스 날짜가 불규칙하기 때문에 기여 일정을 조율하기가 더 어려워집니다.
  • “릴리스를 놓친다”는 것에 대한 스트레스 때문에 Beta 1 이전(그리고 심지어 그 이후에도!) 서두른 커밋이 몰려듭니다.
  • 역설적이게도, Beta 1 이후에는 다음 릴리스까지 “시간이 충분하다”는 잘못된 인식을 갖게 되지만, 그 시간은 어차피 금방 지나갑니다.
  • 워크플로우의 특정 요소들이 너무 드물게 실행되는 탓에 자동화는커녕 명시적으로 문서화조차 되지 않습니다.

더 중요한 것은, 사용자의 관점에서 보면:

  • 많은 새 기능이 담긴 릴리스가 만들어지는데, 그중 일부는 명시적으로 호환되지 않고 일부는 실수로 호환되지 않게 되어, 매번 업그레이드 비용이 상대적으로 높아집니다.
  • 사용자가 사용할 수 있게 되기까지 새 기능과 호환되지 않는 버그 수정이 1년 넘게 묵혀지며, 더 구체적으로는
  • 모든 “점 제로(point zero)” 릴리스가 사용자에게 특히 위험해집니다. 저희는 알파와 베타를 통한 테스트를 제공하고 권장하지만, 많은 사용자에게 “점 제로”는 해당 파이썬 버전의 첫 번째 릴리스입니다. 릴리스가 기능적으로 클수록, “점 제로 릴리스”에 잠재적인 문제가 더 많이 숨어 있게 됩니다.

릴리스 주기를 두 배로 늘려 기능 버전 간 9개월 간격을 달성

이것은 원래 PEP 596에서 제안되었으나 너무 불규칙적이고 너무 짧다는 이유로 거부되었습니다. 이는 정기 릴리스 일정의 이점을 전혀 제공하지 못하면서도 모든 개발 단계, 특히 베타 + RC 단계를 단축시킬 것입니다. 이는 위험한 것으로 간주되었습니다.

“4개월에 걸친 4번의 베타와 릴리스 후보를 위한 마지막 한 달” 유지

이렇게 하면 릴리스 일정이 조금 더 깔끔해지겠지만, Fedora와 같은 외부 배포자들이 가능한 한 빨리 파이썬의 최신 버전을 릴리스하기가 매우 어려워질 것입니다. 우리는 여기서 파이썬의 일정을 조정하고 있는데, 이를 통해 Fedora가 두 프로젝트가 함께 개발되는 동안 파이썬의 최신 버전을 Fedora의 최신 버전과 통합할 수 있게 되어 두 프로젝트 모두가 더 나아지기를 바랍니다.

릴리스 속도는 늦추되 Beta 1로 기능 개발을 동결하지 않기

이는 PEP 598에 설명되어 있습니다. 이 제안은 “점진적 기능 릴리스(incremental feature release)”와 같은 비표준적인 개념을 포함하고 있어 이해하기 어렵게 만듭니다. 제시된 이점은 불명확한 반면, 이 방식의 생소함은 사용자와 통합자에게 혼란을 줄 실질적인 위험을 안고 있습니다.

장기 지원 릴리스

파이썬의 각 버전은 사실상 장기 지원이며, 5년 동안 지원되고 처음 18개월 동안은 정기적인 버그 수정과 보안 업데이트가 허용됩니다. 나머지 기간 동안에는 보안 업데이트가 수용되어 신속하게 릴리스됩니다.

앞으로 파이썬 2.7과 같은 방식의 연장 지원은 계획되어 있지 않습니다.