PEP 607 – CPython 기능 제공 지연 시간 줄이기
- Author:
- Łukasz Langa <lukasz at python.org>, Steve Dower <steve.dower at python.org>, Alyssa Coghlan <ncoghlan at gmail.com>
- Discussions-To:
- Discourse thread
- Status:
- Final
- Type:
- Informational
- Created:
- 11-Oct-2019
- Python-Version:
- 3.9
- Post-History:
- 20-Oct-2019
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
PEP 602와 PEP 605는 Python 사용자에게 더 작은 기능 모음을 더 자주 제공하는 두 가지 대안적 접근법을 설명합니다(18~24개월마다 새로운 기능 릴리스를 제공하고, 최종 릴리스 6~8개월 전에 첫 바이너리 알파 릴리스가 이루어지는 현재의 접근법과 비교했을 때).
두 PEP 모두 일 년 중 일정한 시기에 정식 릴리스가 이루어지는 릴리스 주기로 전환할 것을 제안합니다(PEP 602는 매년, PEP 605는 격년).
경쟁하는 두 제안 모두의 저자가 작성한 이 PEP는, 릴리스 주기 변경이 바람직하다고 여겨지는 이유와 더불어 두 PEP가 완화하고자 하는 위험 요소에 대한 공통 배경을 제공합니다.
변경 근거
기능 제공 배치 크기 줄이기
여러 개의 큰 변경 사항이 함께 제공되면, 새로 발생하는 문제의 근본 원인을 파악하기 위해 복잡한 조사가 필요할 수 있습니다. 배치 크기가 크면 상대적으로 검증되지 않은 코드가 더 많이 포함되므로, 문제가 실제로 발생할 가능성도 더 높아집니다.
이러한 조사를 단순화하고 사용자가 문제를 겪을 가능성을 줄이는 가장 쉬운 방법은 제공되는 배치의 크기를 줄이는 것입니다.
PEP 602는 CPython의 일반적인 배치 크기를 50% 줄여, 18개월 이상의 변경 사항을 누적하는 대신 매번 12개월분의 변경 사항을 제공하는 직접적인 접근법으로 이 문제를 해결하고자 제안합니다.
PEP 605는 롤링 베타 릴리스 스트림 실행에 옵트인한 Python 사용자 기반의 일부에게 2개월분의 변경 사항을 정기적으로 제공함으로써 이를 해결하고자 제안합니다(Windows 정식 릴리스 대신 Windows Insider 빌드를 실행하거나, Debian 안정판 대신 Debian 테스트판을 실행하는 것과 유사합니다).
기능 제공 지연 시간 줄이기
안정 릴리스만이 상당한 사용자 채택을 얻고 있고 안정 릴리스 사이의 기간이 길 경우, 개발자가 일반 사용에 정말로 준비되기 전에 변경 사항을 안정 릴리스에 밀어 넣고 싶은 매우 강한 유혹이 생깁니다.
PEP 602는 안정 릴리스 사이의 기간을 18개월이 아닌 12개월로 줄여 이 문제를 해결하고자 제안합니다.
PEP 605는 CPython 베타 릴리스를 정기적으로 설치하고 사용하는 Python 사용자 커뮤니티를 적극적으로 조성함으로써, 기능이 안정 릴리스에 고정되기 전에 피드백을 얻을 수 있도록 핵심 개발자가 사전 릴리스 주기 초반에 변경 사항을 제공하기 시작하도록 유인을 제공하여 이를 해결하고자 제안합니다.
릴리스 주기를 달력 연도에 맞추기
현재 릴리스 주기는 명목상 18~24개월이지만, 실제로는 꾸준히 그 범위의 18개월 쪽에 가까웠습니다. 이는 사전 릴리스와 최종 릴리스의 목표 날짜가 릴리스마다 달라진다는 것을 의미하며, 이를 기억하는 유일한 방법은 릴리스 PEP를 확인하거나 해당 날짜를 개인 달력에 추가하는 것뿐입니다. 이는 개인 자원봉사자와 기업 기여자 모두에게 성가신 일이며, PyCon US(보통 4월/5월)나 이제는 연례 행사가 된 핵심 개발 스프린트(보통 9월)와 같은 행사와의 일정 조율도 복잡하게 만듭니다.
PEP 602는 매년 10월에 새로운 릴리스를 발행하고, 이를 기준으로 매년의 사전 릴리스 일정을 정하여 이 문제를 해결하고자 제안합니다.
PEP 605는 릴리스 연도(8월에 새로운 안정 릴리스가 발행되는 해)와 비릴리스 연도(유지 보수 릴리스와 새로운 롤링 베타 릴리스만 발행되는 해)를 번갈아 두어 이 문제를 해결하고자 제안합니다.
사전 릴리스 설계 피드백 주기 개선하기
핵심 인터프리터와 표준 라이브러리 API 변경 사항을 설계할 때의 어려움 중 하나는, 나이틀리 빌드와 현재 사전 릴리스에 대한 피드백을 제공할 수 있는 위치에 있는 사용자 기반이 상대적으로 제한적이라는 점입니다. 이는 API 설계가 이미 정식 X.Y.0 릴리스로 제공된 이후에야 많은 사용자 피드백을 받게 된다는 것을 의미합니다.
API가 일반 API라면, 지원 중단 주기로 인해 그 시점에 발견된 설계 실수를 수정하는 데 말 그대로 몇 년이 걸릴 수 있습니다. API를 잠정적(provisional)이라고 표시하면 명목상 이러한 제약을 피할 방법이 되지만, 실제로 그 자유를 활용하면 다른 문제가 발생합니다.
PEP 602는 이전 안정 릴리스 직후에 알파 기간을 시작하여 이 문제를 해결하고자 제안합니다.
PEP 605는 (라이브러리 및 애플리케이션 호환성 테스트뿐 아니라) 프로덕션 워크로드 실행을 위한 CPython 사전 릴리스 채택을 적극적으로 홍보하고, 이를 합리적인 일로 만들기 위해 필요에 따라 사전 릴리스 관리 프로세스를 조정하여 이 문제를 해결하고자 제안합니다.
(참고: 일부 표준 라이브러리 API는 처음에 PyPI를 통해 별도로 버전이 관리되는 패키지의 일부로 제공된 후, 나중에야 표준 라이브러리에 통합되는 방식에 적합합니다. 이 절은 조기 설계 피드백을 얻는 이러한 접근법이 적용되지 않는, 더 낮은 수준의 API와 라이브러리가 아닌 기능에 관한 내용에 더 가깝습니다)
완화해야 할 위험
현재 상황이 몇 가지 측면에서 개선될 여지가 있지만, Python의 인기는 더 넓은 Python 생태계의 많은 사용자와 다른 참여자들이 현재의 릴리스 관리 프로세스에 충분히 만족하고 있음을 보여줍니다.
Python의 사용자 기반은 너무 크고 너무 다양하여 이곳에서 릴리스 주기를 변경했을 때 생길 수 있는 모든 잠재적 단점을 다루기는 어려우므로, 이 절에서는 대신 PEP 설계에서 구체적으로 고려된 몇 가지 사항만 다룹니다.
이미 일부 릴리스를 건너뛰는 사용자 및 재배포자에게 미치는 영향
모든 사용자와 재배포자가 발표되는 모든 CPython 릴리스 시리즈로 업데이트하는 것은 아니라는 점은 이미 사실입니다(예를 들어, Debian stable과 Ubuntu LTS는 자신들의 24개월 릴리스 주기와 CPython의 일반적인 18개월 주기 사이의 불일치로 인해 때때로 릴리스를 건너뜁니다).
더 빠른 12개월 전체 릴리스 주기를 갖는 PEP 602는 이 범주의 사용자가 이전에는 하나만 건너뛰었을 릴리스를 두 개 건너뛰게 될 수 있음을 의미합니다. 하지만 폐지 예고 기간이 연장되었으므로, 단 하나의 릴리스를 건너뛰는 것으로는 더 이상 폐지 경고를 놓치는 결과로 이어지지 않을 것입니다.
더 느린 24개월 전체 릴리스 주기를 갖는 PEP 605는 역사적으로 이 범주에 속했던 일부 사용자를 “모든 안정 릴리스로 업데이트” 범주로 옮길 수 있습니다.
모든 릴리스로 업데이트하는 사용자 및 재배포자에게 미치는 영향
Python 사용자 다수는 사전 릴리스를 절대 설치하지 않지만, 발표된 후 어느 시점에는 모든 안정 릴리스 시리즈로 업데이트합니다.
PEP 602는 릴리스 간 최소 간격을 12개월로 유지하고 각 릴리스의 18개월 정식 지원 기간을 유지함으로써 이 그룹의 구성원에게 미칠 수 있는 잠재적인 부정적 영향을 완화하는 것을 목표로 합니다.
각 릴리스 브랜치의 18개월 정식 지원 기간을 유지한다는 것은 브랜치가 현재와 거의 동일한 시간을 정식 지원 모드와 보안 수정 전용 모드에서 보내게 됨을 의미합니다(각각 약 18개월과 약 42개월).
PEP 605는 사전 릴리스 기간 동안의 사용을 늘려 출시 시점에 더 넓은 생태계 지원을 받는 더 안정적인 최종 릴리스를 달성함으로써 이 그룹의 구성원에게 미칠 수 있는 잠재적인 부정적 영향을 완화하는 것을 목표로 합니다.
24개월 릴리스 주기에서는 각 릴리스 브랜치가 정식 지원 모드에서는 비례적으로 더 많은 시간을, 보안 수정 전용 모드에서는 더 적은 시간을 보내게 됩니다(각각 약 24개월과 약 36개월).
이 그룹에 미치는 영향에 대한 전체 논의는 개별 PEP에 맡깁니다.
CPython 나이틀리 빌드의 사용자 및 재배포자에게 미치는 영향
그렇게 하는 것이 어려움에도 불구하고, CPython master 브랜치를 직접 사용하거나 게시하는 도전을 이미 감행하고 있는 일부 사용자와 재배포자가 있습니다.
이 그룹에는 PEP 602도 PEP 605도 직접적인 영향을 미치지 않아야 하지만, PEP 605의 롤링 릴리스 스트림 제안은 사용자들이 마스터 브랜치를 직접 사용할 필요 없이 테스트된 롤링 베타 스트림을 채택할 수 있도록 함으로써, 더 많은 사용자가 이러한 사용 방식을 채택하는 데 있어서의 장벽을 낮추는 것을 목표로 합니다.
서드파티 라이브러리 관리자에게 미치는 영향
서드파티 라이브러리 관리자에게 있어, 지원 복잡성의 핵심 원인은 널리 사용되는 서로 다른 파이썬 버전의 수입니다.
PEP 602는 정식 릴리스 사이의 최소 간격을 12개월로 유지함으로써 이 그룹 구성원에게 미칠 수 있는 잠재적 부정적 영향을 완화하는 것을 목표로 합니다.
PEP 605는 정식 릴리스 사이의 간격을 24개월로 늘리고, 각 릴리스 브랜치를 후속 버전이 릴리스된 직후 보안 수정 전용 모드로 전환하는 현재 정책을 유지하며, 새로운 롤링 릴리스 스트림에 대해 “베타” 명명 체계를 유지함으로써(적어도 파이썬 3.9 릴리스 주기 동안), 이 그룹 구성원에게 미칠 수 있는 잠재적 부정적 영향을 완화하는 것을 목표로 합니다.
이 그룹에 미치는 영향에 대한 전체 논의는 각 PEP에 맡깁니다.
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.