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 릴리스만 따라가면 됩니다. 제안된 수치에서는 LTS 릴리스가 (기간과 안정성 양면에서) 지금과 비슷한 지원 주기를 제공합니다.
(알파 버전이나 Mercurial 스냅숏을 설치하는 위험을 감수하지 않고) 빠른 반영과 새 기능 사용을 중시하는 사람들은 새 릴리스 주기에서 지금보다 훨씬 더 많은 이점을 얻을 것입니다.
새 기능이나 개선 사항을 기여하려는 사람들은 자신의 기여가 일반 사용자에게 더 빨리 제공된다는 것을 알기에 기여할 동기가 더 커질 것입니다. 또한 기능 동결 기간이 짧아지면 기능 기여자와 소통하는 일도 덜 번거로워집니다.
논의
다음은 논의를 통해 해결해야 할 미결 사항입니다:
- 위에서 정의한 X(기능 릴리스 사이의 개월 수)와 N(LTS 릴리스당 기능 릴리스 수)을 결정해야 합니다.
- 주어진 X와 N 값에서 LTS가 아닌 버전에 버그 수정 릴리스를 내지 않는 정책이 실현 가능합니까?
- 보안 수정에 대한 정책은 무엇입니까?
- 새 문법 및 이와 비슷한 변경(즉, PEP 3003에서 금지했던 모든 것)을 LTS 버전으로 제한해야 합니까?
- Linux 배포판과 같은 패키저에게는 어떤 영향이 있습니까?
- 릴리스 버전 번호나 그 밖의 식별 자료 및 홍보 자료를 통해 어떤 버전이 일반 기능 릴리스이고 어떤 버전이 LTS 릴리스인지 사용자에게 어떻게 명확히 알릴 수 있습니까? 사용자의 기대를 어떻게 관리해야 합니까?
- 릴리스 주기가 빨라지면 언젠가 3.10 이상에 도달할 수도 있다는 뜻입니까? 일부 사람들은 버전 번호가 항상 십진수 한 자리에 들어갈 것이라는 암묵적인 기대를 드러냈습니다.
최종 결정을 내리기 전에 더 넓은 Python 커뮤니티의 의견을 모으는 커뮤니티 투표나 설문 조사를 진행하면 도움이 될 것입니다.
Copyright
This document has been placed in the public domain.