PEP 6 – 버그 수정 릴리스

Author:: Aahz <aahz at pythoncraft.com>, Anthony Baxter <anthony at interlink.com.au>
Status:: Superseded
Type:: Process
Created:: 15-Mar-2001
Post-History:: 15-Mar-2001, 18-Apr-2001, 19-Aug-2004

Table of Contents

초록
동기
금지 사항
거의 금지에 가까운 사항
금지 사항의 적용 범위
버그 수정 릴리스가 이루어지도록 돕기
버전 번호
절차
패치 차르 이력
이력
참고 문헌
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Note

이 PEP는 폐기되었습니다. 현재 릴리스 정책은 the devguide에 문서화되어 있습니다. 릴리스 프로세스의 메커니즘에 대해서는 PEP 101도 참조하십시오.

초록

파이썬은 역사적으로 개발의 단일 분기만을 가지고 있었으며, 릴리스는 새로운 기능을 추가하는 목적과 버그 수정을 제공하는 목적을 결합하여 수행해 왔습니다(이러한 종류의 릴리스는 “주요 릴리스”라고 지칭됩니다). 이 PEP는 버그 수정을 주된 목적으로 하여, 구 버전의 유지보수 릴리스, 즉 버그 수정 릴리스를 분기하는 방법을 설명합니다.

이 PEP는 버그 수정 릴리스의 존재를 보장하는 것이 아닙니다, 다시 말하지만 절대 아닙니다. 이 PEP는 그러한 작업을 수행하고자 하는 파이썬 커뮤니티 구성원이 충분히 있어 버그 수정 릴리스가 원해질 경우 따라야 할 절차를 규정할 뿐입니다.

동기

소스포지(SourceForge)로의 이전과 함께, 파이썬 개발은 가속화되었습니다. 커뮤니티 일부에서는 이러한 가속화가 지나쳤다는 정서가 있으며, 개발 주기 후반에 이르러 너무 많은 기능이 추가된 상태에서 버그 수정을 얻기 위해 새 버전으로 업그레이드하는 것을 불편해하는 사람들이 많습니다.

이 문제에 대한 한 가지 해결책은 이전 주요 릴리스를 유지보수하여, 다음 주요 릴리스가 나올 때까지 버그 수정을 제공하는 것입니다. 이는 수백 대 또는 수천 대의 머신에 파이썬을 설치해야 할 수도 있는 기업용 개발 환경에서 파이썬을 더 매력적으로 만들어 줄 것입니다.

금지 사항

버그 수정 릴리스는 다음의 제약을 준수해야 합니다:

문법 변경은 절대 있어서는 안 됩니다. 주요 릴리스에서 분기된 모든 버그 수정 릴리스에서 모든 .pyc와 .pyo 파일이 (재생성 없이) 동작해야 합니다.
pickle 변경 사항은 전혀 없어야 합니다.
호환되지 않는 C API 변경 사항은 없어야 합니다. 모든 확장 모듈은 메이저 릴리스와 동일한 포크에 속한 모든 버그 수정 릴리스에서 재컴파일 없이 계속 동작해야 합니다.

이러한 금지 사항 중 하나라도 위반하려면 BDFL 선언(그리고 릴리스 노트에 명확한 경고)이 필요합니다.

거의 금지에 가까운 사항

가능한 경우, 버그 수정 릴리스는 다음 사항도 충족해야 합니다:

새로운 기능이 없어야 합니다. 버그 수정 릴리스의 목적은 버그를 고치는 것이지, CVS 루트의 HEAD에 있는 최신의 멋진 whizzo 기능을 추가하는 것이 아닙니다.
무리 없는 업그레이드여야 합니다. 사용자는 2.x.y에서 2.x.(y+1)로 업그레이드해도 실행 중인 시스템이 깨지지 않을 것이라는 확신을 가질 수 있어야 합니다. 이는 버그를 고치기 위해 필요한 경우가 아니라면, 표준 라이브러리가 동작을, 더 나아가 API를 변경해서는 안 된다는 것을 의미합니다.

금지 사항의 적용 범위

위의 금지 사항과 거의 금지에 가까운 사항은 최종 릴리스에서 버그 수정 릴리스로의 전환(예를 들어, 2.4에서 2.4.1로)과, 시리즈 내에서 한 버그 수정 릴리스에서 다음 버그 수정 릴리스로의 전환(예를 들어, 2.4.1에서 2.4.2로) 모두에 적용됩니다.

이 PEP에 나열된 금지 사항을 따르는 것은 버그 수정 릴리스가 무리 없고 안전한 업그레이드라는 인식을 커뮤니티가 계속 만족스럽게 느끼도록 돕는 데 도움이 될 것입니다.

버그 수정 릴리스가 이루어지도록 돕기

버그 수정 릴리스 과정을 돕는 데 유용한 몇 가지 방법을 소개합니다.

버그 수정 사항을 백포트하십시오. 버그를 수정했고 적절하다고 판단되면, 현재 버그 수정 릴리스를 위한 CVS 브랜치로 이식하십시오. 직접 백포트할 의사가 없거나 할 수 없는 경우, 커밋 메시지에 ‘Bugfix candidate’ 또는 ‘Backport candidate’와 같은 문구로 메모를 남기십시오.
확신이 서지 않으면 문의하십시오. 특정 수정 사항이 적절하다고 생각하는지 현재 버그 수정 릴리스를 관리하는 담당자에게 문의하십시오.
버그 수정 릴리스에 특별히 수정되기를 바라는 특정 버그가 있다면, 적극적으로 나서서 처리되도록 노력하십시오. 버그 수정 릴리스 예정일 48시간 전까지 기다렸다가 그제야 버그 수정 사항 포함을 요청하기 시작하지 마십시오.

버전 번호

Python 2.0부터 모든 주요 릴리스는 X.Y 형식의 버전 번호를 가져야 하며, 버그 수정 릴리스는 항상 X.Y.Z 형식을 가집니다.

현재 개발 중인 주요 릴리스는 릴리스 N으로, 방금 출시된 주요 버전은 N-1로 지칭합니다.

CVS에서 버그 수정 릴리스는 브랜치 상에서 이루어집니다. 릴리스 2.x의 경우, 브랜치 이름은 ‘release2x-maint’입니다. 예를 들어, 2.3 유지보수 릴리스를 위한 브랜치는 release23-maint입니다.

절차

버그 수정 릴리스 관리 프로세스는 부분적으로 Tcl 시스템 [1]을 본떠 만들어졌습니다.

패치 차르(Patch Czar)는 버그 수정 릴리스에 대해 BDFL에 대응하는 역할을 합니다. 그러나 BDFL과 지정된 대리인은 개별 패치에 대한 거부권을 계속 유지합니다. 패치 차르는 개발의 단일 브랜치만을 관리할 수도 있습니다 - 서로 다른 사람이 2.3.x와 2.4.x 릴리스를 각각 관리하는 것도 충분히 가능한 일입니다.

개별 패치가 CVS의 현재 트렁크에 기여됨에 따라, 각 패치 커미터는 해당 패치가 버그 수정 릴리스에 포함하기에 적합한 버그 수정인지 검토하도록 요청받습니다. 패치가 적합하다고 판단되면, 커미터는 해당 릴리스를 유지 관리 브랜치에 커밋하거나, 커밋 메시지에 해당 패치를 표시할 수 있습니다.

또한 파이썬 커뮤니티의 누구나 자유롭게 패치를 포함시켜 달라고 제안할 수 있습니다. 패치는 버그 수정 릴리스를 위해 특별히 제출될 수 있으며, 이 경우 PEP 3의 지침을 따라야 합니다. 다만 일반적으로는 특정 릴리스의 버그를 브랜치뿐만 아니라 HEAD에서도 함께 수정하는 편이 더 나을 것입니다.

패치 차르는 릴리스를 정당화할 만큼 충분한 수의 패치가 모였는지를 판단합니다. 해당 릴리스는 윈도우 설치 프로그램을 포함하여 패키징된 후 공개됩니다. 새로운 버그가 발견되면 즉시 수정해야 하며, (버전 번호를 올린) 새로운 버그 수정 릴리스를 공지해야 합니다. 2.3.x 주기 동안 패치 차르(앤서니)는 대략 6개월마다 릴리스를 내려고 노력해 왔지만, 이것이 향후 릴리스에 어떤 식으로든 구속력을 갖는 것으로 간주되어서는 안 됩니다.

버그 수정 릴리스는 대략 6개월 간격으로 이루어질 것으로 예상됩니다. 하지만 이는 어디까지나 지침일 뿐입니다 - 당연히, 중대한 버그가 발견되면 버그 수정 릴리스가 더 일찍 적절할 수 있습니다. 일반적으로 어느 시점에서든 N-1 릴리스만이 활발한 유지 보수 대상이 됩니다. 즉, Python 2.4의 개발 기간 동안에는 Python 2.3이 버그 수정 릴리스를 받습니다. 하지만 자격을 갖춘 누군가가 더 오래된 릴리스의 유지 보수 작업을 계속하고자 한다면, 이는 장려되어야 합니다.

패치 차르 이력

Anthony Baxter가 2.3.1부터 2.3.4까지의 패치 차르입니다.

Barry Warsaw가 2.2.3의 패치 차르입니다.

Guido van Rossum이 2.2.2의 패치 차르입니다.

Michael Hudson이 2.2.1의 패치 차르입니다.

Anthony Baxter가 2.1.2와 2.1.3의 패치 차르입니다.

Thomas Wouters가 2.1.1의 패치 차르입니다.

Moshe Zadka가 2.0.1의 패치 차르입니다.

이력

이 PEP는 comp.lang.python의 한 제안으로 시작되었습니다. 원래 버전은 N 릴리스와 동시에 배포될 N-1 릴리스용 단일 패치를 제안했습니다. 원래 버전은 또한 엄격한 버그 수정 정책을 고수해야 한다고 주장했습니다.

BDFL과 다른 사람들의 피드백에 따라, 이전의 모든 주요 릴리스가 패치를 받을 수 있도록 버그 수정 릴리스 주기를 확장하고 엄격한 버그 수정 요건을 완화한(주로 버그 수정으로도 기능으로도 볼 수 있는 PEP 235의 사례 때문에) 초안 PEP가 작성되었습니다.

그 후 논의는 대부분 python-dev로 옮겨갔으며, 그곳에서 BDFL은 마침내 Python의 버그 수정 릴리스 프로세스를 Tcl의 방식에 기반하도록 선언했는데, 이는 N-1 릴리스에만 해당하고 버그 수정만 포함한다는 점에서 본질적으로 원래 제안으로 돌아간 것이지만, N 릴리스가 배포될 때까지 여러 차례의 버그 수정 릴리스를 허용했습니다.

이후 Anthony Baxter가 이 PEP를 넘겨받아 2.3 릴리스 주기의 교훈을 바탕으로 개정했습니다.

참고 문헌

Copyright

This document has been placed in the public domain.