Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

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 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

Note

이 PEP는 폐기되었습니다. 현재 릴리스 정책은 개발자 가이드에 문서화되어 있습니다. 릴리스 절차의 구체적인 진행 방식은 PEP 101도 참고하십시오.

초록

역사적으로 Python에는 개발 분기가 단 하나뿐이었으며, 릴리스는 새 기능 추가와 버그 수정 제공이라는 목적을 함께 지녔습니다(이러한 종류의 릴리스를 “메이저 릴리스”라고 부르겠습니다). 이 PEP는 버그 수정을 주된 목적으로 하여 이전 버전의 유지 보수 릴리스, 즉 버그 수정 릴리스를 분기해 내는 방법을 설명합니다.

이 PEP는 버그 수정 릴리스가 나온다는 것을 보장하지 않습니다. 다시 말하지만, 결코 보장하지 않습니다. 이 PEP는 그 작업을 기꺼이 맡으려는 Python 커뮤니티 구성원이 충분히 많아 버그 수정 릴리스를 원할 경우에 따라야 할 절차만을 규정합니다.

동기

SourceForge로 이전한 이후 Python 개발 속도가 빨라졌습니다. 커뮤니티 일부에서는 속도가 지나치게 빨라졌다고 느끼고 있으며, 때로는 개발 주기 후반까지도 매우 많은 기능이 추가된 상황에서 버그 수정을 받으려고 새 버전으로 업그레이드하는 것을 불편해하는 사람이 많습니다.

이 문제에 대한 한 가지 해결책은 이전 메이저 릴리스를 유지 보수하면서 다음 메이저 릴리스가 나올 때까지 버그 수정을 제공하는 것입니다. 이렇게 하면 Python을 수백 대 또는 수천 대의 기계에 설치해야 할 수도 있는 기업 개발 환경에서 Python이 더 매력적인 선택지가 될 것입니다.

금지 사항

버그 수정 릴리스는 다음 제약 사항을 반드시 준수해야 합니다.

  1. 문법 변경이 전혀 없어야 합니다. 모든 .pyc 및 .pyo 파일은 한 메이저 릴리스에서 분기된 모든 버그 수정 릴리스에서 (다시 생성할 필요 없이) 동작해야 합니다.
  2. pickle 변경이 전혀 없어야 합니다.
  3. 호환되지 않는 C API 변경이 없어야 합니다. 모든 확장 모듈은 메이저 릴리스와 같은 분기에 속한 모든 버그 수정 릴리스에서 다시 컴파일하지 않고도 계속 동작해야 합니다.

이 금지 사항 중 어느 하나라도 어기려면 BDFL의 선언(그리고 릴리스 노트의 눈에 띄는 경고)이 필요합니다.

준금지 사항

가능하다면 버그 수정 릴리스는 다음 사항도 지켜야 합니다.

  1. 새 기능이 없어야 합니다. 버그 수정 릴리스의 목적은 버그를 수정하는 것이지, CVS 루트의 HEAD에 있는 최신의 화려한 기능을 추가하는 것이 아닙니다.
  2. 부담 없는 업그레이드여야 합니다. 사용자는 2.x.y에서 2.x.(y+1)로 업그레이드해도 운영 중인 시스템이 망가지지 않으리라고 확신할 수 있어야 합니다. 이는 버그 수정에 필요한 경우가 아니라면 표준 라이브러리의 동작이 바뀌어서는 안 되며, API가 바뀌는 것은 더더욱 안 된다는 뜻입니다.

금지 사항의 적용 범위

위의 금지 사항과 준금지 사항은 최종 릴리스에서 버그 수정 릴리스로 넘어가는 경우(예를 들어 2.4에서 2.4.1로)와 한 시리즈 안에서 버그 수정 릴리스에서 다음 버그 수정 릴리스로 넘어가는 경우(예를 들어 2.4.1에서 2.4.2로) 모두에 적용됩니다.

이 PEP에 나열된 금지 사항을 따르면, 버그 수정 릴리스가 부담 없고 안전한 업그레이드라는 점에 커뮤니티가 계속 만족하는 데 도움이 될 것입니다.

버그 수정 릴리스가 나올 수 있도록 돕기

다음은 버그 수정 릴리스 과정을 돕기 위한 몇 가지 조언입니다.

  1. 버그 수정 사항을 백포트하십시오. 버그를 수정했고 그것이 적절해 보인다면, 현재 버그 수정 릴리스를 위한 CVS 브랜치로 이식하십시오. 직접 백포트할 의향이 없거나 백포트할 수 없다면, 커밋 메시지에 ‘버그 수정 후보(Bugfix candidate)’나 ‘백포트 후보(Backport candidate)’ 같은 문구를 남기십시오.
  2. 확실하지 않다면 물어보십시오. 특정 수정 사항이 적절하다고 생각하는지 현재 버그 수정 릴리스를 관리하는 사람에게 물어보십시오.
  3. 버그 수정 릴리스에서 꼭 수정되었으면 하는 특정 버그가 있다면, 적극적으로 나서서 해결되도록 노력하십시오. 버그 수정 릴리스 예정일 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의 현재 트렁크에 기여될 때, 각 패치 커미터는 해당 패치가 버그 수정 릴리스에 포함하기에 적합한 버그 수정인지 검토하도록 요청받습니다. 패치가 적합하다고 판단되면, 커미터는 릴리스를 유지보수 브랜치에 커밋하거나, 커밋 메시지에 해당 패치를 표시할 수 있습니다.

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

패치 차르는 릴리스를 낼 만큼 패치가 충분히 모였는지 판단합니다. 릴리스는 Windows 설치 프로그램을 포함하여 패키징된 후 공개됩니다. 새로운 버그가 발견되면 즉시 수정해야 하며, (버전 번호를 올린) 새 버그 수정 릴리스를 공개해야 합니다. 2.3.x 주기 동안 패치 차르(Anthony)는 대략 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-1 릴리스에 대한 단일 패치를 N 릴리스와 동시에 릴리스할 것을 제안했습니다. 최초 버전은 또한 엄격한 버그 수정 정책을 고수해야 한다고 주장했습니다.

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

이후 논의는 주로 python-dev로 옮겨 갔고, 그곳에서 BDFL이 마침내 Python 버그 수정 릴리스 절차를 Tcl의 절차에 기반하도록 하는 선언을 발표했습니다. 이는 N-1 릴리스만, 그리고 버그 수정만 다룬다는 점에서 사실상 최초 제안으로 돌아간 것이었지만, N 릴리스가 공개될 때까지 여러 번의 버그 수정 릴리스를 허용했습니다.

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

참고 문헌