[Deferred] PEP 407 - New release cycle and introducing long-term support versions

September 26, 2025

원문 링크: PEP 407 - New release cycle and introducing long-term support versions

상태: Deferred 유형: Process 작성일: 12-Jan-2012

PEP 407 – 새로운 릴리스 주기 및 장기 지원 버전 도입

작성자: Antoine Pitrou, Georg Brandl, Barry Warsaw
상태: 보류됨 (Deferred)
유형: Process
생성일: 2012년 1월 12일
최종 수정일: 2025년 2월 1일

개요

오픈 소스 프로젝트의 릴리스 주기(release cycle)를 결정하는 것은 상호 모순되는 제약 조건들을 관리하는 섬세한 작업입니다. 이에는 개발자 인력, 릴리스 관리 자원봉사자 확보, 사용자 및 서드파티 패키지 관리의 용이성, 새로운 기능 및 행동 변경 사항의 신속한 제공, 새로운 기능이나 행동 변경 없이 버그 수정 제공 등이 포함됩니다.

현재의 릴리스 주기는 보수적인 측면이 강합니다. 이는 반응성(reactivity)보다 안정성을 중시하는 사람들에게 적합합니다. 이 PEP는 Python의 특징이 된 안정성을 유지하면서, 장기 지원(Long-Term Support, LTS) 버전의 개념을 도입하여 기능 릴리스를 더욱 유연하게 제공하려는 시도입니다.

범위

이 PEP는 2.7 브랜치(branch)의 유지보수 기간이나 릴리스 방식을 변경하려 하지 않습니다. 오직 3.x 버전만이 고려 대상입니다.

제안

제안된 방식에 따르면, 두 가지 종류의 기능 버전(feature versions, 때때로 3.2 또는 3.3과 같은 “마이너 버전”으로 불림)이 있을 것입니다: 일반 기능 버전(normal feature versions)과 장기 지원(LTS) 버전.

일반 기능 버전: 버그 수정 릴리스가 전혀 없거나, 최대 한 번만 제공됩니다. 후자는 중요한 문제 해결이 필요한 경우에 한합니다. 이러한 브랜치에 대한 보안 수정(security fix) 처리 방안은 결정될 필요가 있습니다.
LTS 버전: 다음 LTS 버전이 나올 때까지 정기적인 버그 수정 릴리스가 제공됩니다. 그 후에는 릴리스 관리자(release manager)의 재량에 따라 종료일까지 보안 수정 모드로 전환됩니다.

주기 (Periodicity)

새로운 기능 버전은 X개월마다 릴리스됩니다. 잠정적으로 X는 6개월로 제안됩니다.

LTS 버전은 N개의 기능 버전 중 하나가 됩니다. 잠정적으로 N은 4로 제안됩니다.

이러한 수치에 따르면, 새로운 LTS 버전은 24개월마다 출시되며, 다음 LTS 버전이 24개월 후에 나올 때까지 지원됩니다. 이는 현재의 모든 기능 버전에 대한 18개월 버그 수정 주기와 다소 유사합니다.

사전 릴리스 버전 (Pre-release versions)

더 빈번한 기능 릴리스는 릴리스당 파괴적인 변경(disruptive changes)의 수를 줄인다는 것을 의미합니다. 따라서 사전 릴리스 빌드(pre-release builds, 알파 및 베타)의 수를 상당히 줄일 수 있습니다. 일반적인 경우 두 개의 알파 빌드와 하나의 베타 빌드면 충분할 것입니다. 릴리스 후보(release candidates)의 수는 최종 릴리스 전의 막바지 수정 사항(last-minute fixes) 수에 따라 달라집니다.

영향

개발 주기(Development Cycle)에 미치는 영향

더 많은 기능 릴리스는 개발 및 릴리스 관리 팀에 더 많은 부담을 줄 수 있습니다. 이는 사전 릴리스 버전 수 감소로 정량적으로 완화되며, 파괴적인 변경 사항 감소(이는 잠재적인 손상 가능성 감소를 의미)로 정성적으로 완화됩니다. 짧아진 기능 동결(feature freeze) 기간(첫 번째 베타 빌드부터 최종 릴리스까지)은 받아들이기 더 쉽습니다. 기능 동결 직전 기능을 추가하기 위한 서두름도 훨씬 줄어들 것입니다.

버그 수정 주기(Bugfix Cycle)에 미치는 영향

제안된 수치로 볼 때 버그 수정에 미치는 영향은 최소화될 것입니다. 동일한 수의 브랜치가 버그 수정 유지보수(2.x 종료 시까지는 두 개, 그 이후에는 한 개)를 위해 동시에 열려 있을 것입니다.

워크플로우(Workflow)에 미치는 영향

새로운 기능에 대한 워크플로우는 동일합니다: 개발자들은 기본 브랜치(default branch)에만 커밋(commit)할 것입니다.

버그 수정에 대한 워크플로우는 약간 업데이트될 것입니다: 개발자들은 버그 수정 사항을 현재 LTS 브랜치(예: 3.3)에 커밋하고, 그 다음 기본 브랜치로 병합(merge)할 것입니다.

만약 비(非) LTS 버전에 대한 중요한 수정 사항이 필요한 경우, 현재 LTS 브랜치에서 비 LTS 브랜치로 이식(graft)될 수 있습니다. 이는 오늘날 3.x에서 2.7로 수정 사항이 포팅(porting)되는 방식과 유사합니다.

커뮤니티(Community)에 미치는 영향

안정성을 중시하는 사용자: 제안된 수치로 인해 지원 기간과 안정성 모두에서 유사한 지원 주기를 제공할 LTS 릴리스에 맞춰 동기화할 수 있습니다.
반응성 및 새로운 기능을 중시하는 사용자: 알파 버전이나 Mercurial 스냅샷을 설치할 위험을 감수하지 않고도 새로운 릴리스 주기에서 훨씬 더 많은 가치를 얻을 수 있습니다.
기능 기여자: 자신의 기여가 일반 사용자들에게 더 빨리 제공될 것을 알게 되므로, 새로운 기능이나 개선 사항에 기여하려는 동기가 더 커질 것입니다. 또한, 짧아진 기능 동결 기간은 기능 기여자들과의 상호 작용을 덜 번거롭게 만듭니다.

논의 (Discussion)

다음은 논의 과정에서 해결되어야 할 공개된 문제들입니다:

위에서 정의된 X (기능 릴리스 간의 개월 수) 및 N (LTS 릴리스당 기능 릴리스 수)에 대한 결정.
X와 N의 특정 값에 대해 비(非) LTS 버전에 대한 버그 수정 릴리스 없음 정책이 실현 가능한가?
보안 수정에 대한 정책은 무엇인가?
새로운 문법 및 유사한 변경 사항(즉, PEP 3003에 의해 금지되었던 모든 것)을 LTS 버전으로 제한할 것인가?
Linux 배포판과 같은 패키지 관리자(packagers)에게 미치는 영향은 무엇인가?
릴리스 버전 번호 또는 기타 식별 및 마케팅 자료가 사용자에게 어떤 버전이 일반 기능 릴리스이고 어떤 버전이 LTS 릴리스인지 명확하게 전달하는 방법은 무엇인가?
사용자 기대치를 어떻게 관리할 것인가?
더 빠른 릴리스 주기가 언젠가 3.10 이상에 도달할 수 있다는 것을 의미하는가? 일부 사람들은 버전 번호가 항상 한 자리 숫자에 맞춰져야 한다는 암묵적인 기대를 표명했다.

최종 결정을 내리기 전에 더 넓은 Python 커뮤니티의 의견을 수렴하기 위한 커뮤니티 여론 조사나 설문 조사가 가치 있을 것입니다.

이 문서는 퍼블릭 도메인(public domain)에 있습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.