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 릴리스 일정의 변경 사항을 설명합니다. 이 변경으로 릴리스 주기가 빨라져, 기능 버전이 매년 10월에 12개월 간격으로 예측 가능하게 릴리스됩니다.

구현

기능 버전 개발 기간 17개월

이 PEP는 Python 3.X.0을 약 17개월 동안 개발할 것을 제안합니다:

  • 처음 5개월은 Python 3.(X-1).0의 베타 및 릴리스 후보 단계와 겹치므로 버전이 붙지 않습니다.
  • 다음 7개월은 버전이 붙은 알파 릴리스 기간으로, 새 기능이 점진적으로 추가되고 버그 수정도 포함됩니다.
  • 그다음 3개월은 버전이 붙은 네 번의 베타 릴리스 기간으로, 새 기능은 추가할 수 없지만 버그 수정은 계속 포함됩니다.
  • 마지막 2개월은 두 번(필요하면 그 이상)의 릴리스 후보 기간이며, Python 3.X.0 최종 릴리스로 마무리됩니다.

2년간의 전체 지원과 이후 3년간의 보안 수정

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

  • 처음 24개월 (2년) 동안은 버그 수정 업데이트를 받으며, 전체 릴리스(소스 및 Windows와 macOS용 설치 프로그램)가 약 두 달마다 이루어집니다.
  • 다음 36개월 (3년) 동안은 보안 업데이트를 받으며, 소스 전용 릴리스가 필요에 따라(고정된 주기 없이) 이루어집니다.
  • 마지막 소스 전용 릴리스는 3.X.0으로부터 5년 후에 이루어집니다.

참고: 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-06-04
  • 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-01-13
  • 3.9.0 알파 5: 월요일, 2020-02-17
  • 3.9.0 알파 6: 월요일, 2020-03-16
  • 3.9.0 알파 7: 월요일, 2020-04-13
  • 3.9.0 베타 1: 월요일, 2020-05-18 (이 시점 이후로는 새 기능이 추가되지 않습니다.)
  • 3.9.0 베타 2: 월요일, 2020-06-08
  • 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는 이 정책을 유지하되, 운영 위원회와 릴리스 관리자 모임(Cabal of Release Managers)의 승인을 받아 임기를 더 많은 릴리스로 연장할 수 있도록 할 것을 제안합니다.

특히 이 PEP는 현직 릴리스 관리자가 작성했고 그 효과로 릴리스 관리자의 임기가 짧아지므로, 저자는 이로 인한 혼란을 보상하기 위해 세 번째 기능 릴리스의 관리까지 맡을 의향이 있습니다.

근거와 목표

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

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

목표가 아닌 것

연간 릴리스 일정을 채택하면 달력 기반 버전 관리로 자연스럽게 전환할 수 있습니다. 예를 들어 Python 3.9는 ‘20년 10월에 릴리스되므로 “Python 3.20”이라고 부르는 식입니다(“Python 3.23”은 ‘23년 10월에 릴리스되는 버전이 됩니다).

달력 기반 버전 관리로 쉽게 전환할 수 있다는 점을 연간 릴리스 주기의 장점으로 볼 수도 있지만, 이 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개월 릴리스 주기 유지

이는 코어 개발자와 최종 사용자 모두에게 바람직하지 않습니다. 코어 개발자의 관점에서 보면 다음과 같습니다.

  • 해마다 릴리스 날짜가 불규칙하여 기여 일정을 세우기가 더 어려워집니다.
  • “릴리스를 놓치는 것”에 대한 스트레스 때문에 베타 1 이전에(심지어 이후에도!) 서둘러 만든 커밋이 급증합니다.
  • 역설적으로, 베타 1 이후에는 다음 릴리스까지 “시간이 충분하다”는 착각을 불러일으키지만, 그 시간은 어쨌든 빠르게 지나갑니다.
  • 워크플로의 특정 요소가 너무 드물게 실행되어 자동화는커녕 명시적으로 문서화조차 되지 않습니다.

더 중요한 것으로, 사용자의 관점에서 보면 다음과 같습니다.

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

릴리스 주기를 두 배로 빠르게 하여 기능 버전 사이의 간격을 9개월로 만들기

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

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

이렇게 하면 릴리스 일정이 조금 더 깔끔해지겠지만, Fedora와 같은 외부 배포자가 최신 버전의 Python을 가능한 한 빨리 릴리스하기가 매우 어려워집니다. 여기서 Python의 일정을 조정하는 것은 Fedora가 최신 버전의 Python을 최신 버전의 Fedora와 둘 다 개발되는 동안 통합할 수 있기를 바라기 때문이며, 이는 두 프로젝트 모두를 더 좋게 만듭니다.

릴리스 속도를 늦추되 베타 1에서 기능 개발을 동결하지 않기

이 방안은 PEP 598에 설명되어 있습니다. 이 제안에는 “점진적 기능 릴리스”와 같은 비표준 개념이 포함되어 있어 이해하기 어렵습니다. 제시된 이점은 불분명한 반면, 이 방식이 익숙하지 않아 사용자와 통합자가 혼란을 겪을 실질적인 위험이 있습니다.

장기 지원 릴리스

Python의 각 버전은 사실상 장기 지원 버전입니다. 5년 동안 지원되며, 처음 18개월 동안은 일반 버그 수정과 보안 업데이트가 허용됩니다. 나머지 기간에는 보안 업데이트가 받아들여지며 신속하게 릴리스됩니다.

앞으로 Python 2.7과 같은 방식의 확장 지원은 계획되어 있지 않습니다.