PEP 407 – 새로운 릴리스 주기 및 장기 지원 버전 도입
- Author:
- Antoine Pitrou <solipsis at pitrou.net>, Georg Brandl <georg at python.org>, Barry Warsaw <barry at python.org>
- Status:
- Deferred
- Type:
- Process
- Created:
- 12-Jan-2012
- Post-History:
- 17-Jan-2012
Table of Contents
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
오픈 소스 프로젝트의 릴리스 주기를 정하는 일은 개발자 인력, 릴리스 관리 자원봉사자의 가용성, 사용자와 서드파티 패키지 관리자의 유지 관리 편의성, 새로운 기능과 동작 변경의 신속한 제공, 새로운 기능이나 동작 변경을 포함하지 않는 버그 수정의 제공이라는 서로 상충하는 제약을 관리해야 하는 섬세한 작업입니다.
현재 릴리스 주기는 보수적인 측면에 치우쳐 있습니다. 안정성을 신속한 대응보다 중시하는 사람들에게는 적절합니다. 이 PEP는 장기 지원 버전이라는 개념을 도입하여, Python의 상징이 된 안정성을 유지하면서 더욱 유연하게 기능을 릴리스하려는 시도입니다.
범위
이 PEP는 2.7 브랜치의 유지 관리 기간이나 릴리스 방식을 변경하려는 것이 아닙니다. 3.x 버전만 고려합니다.
제안
제안된 방식에서는 두 종류의 기능 버전(예를 들어 3.2 또는 3.3이며, 때때로 “마이너 버전”이라고도 합니다)이 존재합니다. 일반 기능 버전과 장기 지원(LTS) 버전입니다.
일반 기능 버전에는 버그 수정 릴리스가 없거나 최대 한 번만 제공되며, 후자의 경우에도 심각한 문제를 수정해야 할 때만 제공됩니다. 이러한 브랜치의 보안 수정 처리는 결정해야 합니다.
LTS 버전에는 다음 LTS 버전이 출시될 때까지 정기적인 버그 수정 릴리스가 제공됩니다. 그 이후에는 릴리스 관리자가 재량으로 정한 종료일까지 보안 수정 모드로 전환됩니다.
주기성
새로운 기능 버전은 X개월마다 릴리스됩니다. 잠정적으로 X = 6개월을 제안합니다.
LTS 버전은 N개의 기능 버전 중 하나로 지정됩니다. 잠정적으로 N = 4를 제안합니다.
이 수치를 적용하면 새로운 LTS 버전은 24개월마다 출시되며, 24개월 후 다음 LTS 버전이 출시될 때까지 지원됩니다. 이는 각 기능 버전에 대해 현재 적용되는 18개월 버그 수정 주기와 어느 정도 유사합니다.
프리릴리스 버전
기능을 더 자주 릴리스하면 릴리스마다 호환성을 깨뜨리는 변경 사항의 수가 줄어듭니다. 따라서 프리릴리스 빌드(알파 및 베타)의 수를 상당히 줄일 수 있습니다. 일반적인 경우에는 알파 빌드 두 개와 베타 빌드 하나면 충분할 것입니다. 릴리스 후보의 수는 평소와 같이 최종 릴리스 전에 이루어지는 막바지 수정의 수에 따라 달라집니다.
영향
개발 주기에 미치는 영향
더 많은 기능 릴리스는 개발 및 릴리스 관리 팀에 더 많은 부담을 의미할 수 있습니다. 이는 양적으로는 더 적은 수의 사전 릴리스 버전으로 완화되며, 질적으로는 더 적은 양의 파괴적 변경(즉 손상 가능성이 낮음)으로 완화됩니다. 더 짧아진 기능 동결 기간(첫 번째 베타 빌드 이후부터 최종 릴리스까지)은 받아들이기 더 쉽습니다. 기능 동결 직전에 기능을 추가하려는 조급함 역시 훨씬 줄어들 것입니다.
버그 수정 주기에 미치는 영향
제안된 수치로는 버그 수정에 미치는 영향이 최소화될 것입니다. 버그 수정 유지보수를 위해 동시에 열려 있는 브랜치 수는 동일하게 유지됩니다(2.x가 종료될 때까지는 두 개, 이후에는 한 개).
작업 흐름에 미치는 영향
새 기능에 대한 작업 흐름은 동일하게 유지됩니다: 개발자는 default 브랜치에만 커밋합니다.
버그 수정에 대한 작업 흐름은 약간 변경됩니다: 개발자는 현재 LTS 브랜치(예: 3.3)에 버그 수정을 커밋한 다음 default로 병합합니다.
비LTS 버전에 긴급한 수정이 필요한 경우, 오늘날 3.x에서 2.7로 수정 사항이 이식되는 것과 마찬가지로 현재 LTS 브랜치에서 비LTS 브랜치로 이식할 수 있습니다.
커뮤니티에 미치는 영향
안정성을 중시하는 사람들은 LTS 릴리스에만 맞춰가면 되며, 제안된 수치로는 (기간과 안정성 양면에서) 비슷한 지원 주기를 얻을 수 있습니다.
반응성과 새 기능에 대한 접근을 중시하는 사람들(알파 버전이나 Mercurial 스냅샷을 설치하는 위험을 감수하지 않고도)은 현재보다 새로운 릴리스 주기에서 훨씬 더 많은 이득을 얻을 것입니다.
새 기능이나 개선 사항을 기여하고자 하는 사람들은 자신의 기여가 일반 사용자에게 더 빨리 제공된다는 것을 알기에 더욱 동기부여될 것입니다. 또한 더 짧아진 기능 동결 기간은 기능 기여자들과의 소통을 덜 번거롭게 만듭니다.
논의
다음은 논의 과정에서 해결되어야 할 미결 사안들입니다:
- 위에서 정의한 X(기능 릴리스 사이의 개월 수)와 N(LTS 릴리스당 기능 릴리스 수)을 결정합니다.
- 주어진 X와 N 값에 대해, 비LTS 버전에 대한 버그 수정 릴리스 없음 정책이 실행 가능한가?
- 보안 수정에 대한 정책은 무엇인가?
- 새로운 문법 및 유사한 변경 사항(즉 PEP 3003에서 금지된 모든 것)을 LTS 버전으로 제한할 것인가?
- 리눅스 배포판과 같은 패키저에 미치는 영향은 무엇인가?
- 릴리스 버전 번호나 기타 식별·마케팅 자료가 어떤 버전이 일반 기능 릴리스이고 어떤 버전이 LTS 릴리스인지를 사용자에게 어떻게 명확히 알릴 것인가? 사용자의 기대를 어떻게 관리할 것인가?
- 더 빨라진 릴리스 주기는 언젠가 3.10 이상에 도달할 수 있음을 의미하는가? 일부 사람들은 버전 번호가 항상 한 자리 십진수에 들어맞아야 한다는 암묵적인 기대를 표명했습니다.
최종 결정을 내리기 전에 파이썬 커뮤니티 전체의 의견을 수집하기 위한 커뮤니티 투표나 설문조사가 유용할 것입니다.
Copyright
This document has been placed in the public domain.