[Superseded] PEP 6 - Bug Fix Releases

원문 링크: PEP 6 - Bug Fix Releases

상태: Superseded 유형: Process 작성일: 15-Mar-2001

PEP 6 – Bug Fix Releases (버그 수정 릴리스)

저자: Aahz , Anthony Baxter **상태:** Superseded (대체됨) **유형:** Process (프로세스) **생성일:** 2001년 3월 15일 **이력:** 2001년 3월 15일, 2001년 4월 18일, 2004년 8월 19일

참고: 이 PEP는 더 이상 사용되지 않습니다 (obsolete). 현재 릴리스 정책은 개발 가이드(devguide)에 문서화되어 있습니다. 릴리스 프로세스의 메커니즘에 대해서는 PEP 101을 참조하세요.

요약 (Abstract)

Python은 역사적으로 단일 개발 포크(fork)만을 가지고 있었으며, 릴리스는 새로운 기능 추가와 버그 수정이라는 두 가지 목적을 동시에 수행했습니다 (이러한 종류의 릴리스는 “주요 릴리스(major releases)”라고 불립니다). 이 PEP는 주로 버그 수정을 목적으로 구버전의 유지보수 또는 버그 수정 릴리스를 포크하는 방법을 설명합니다.

이 PEP는 버그 수정 릴리스의 존재를 보장하는 것이 아니며, 버그 수정 릴리스가 필요한 만큼의 Python 커뮤니티 구성원이 기꺼이 작업을 수행할 의향이 있을 경우에 따를 절차만을 명시합니다.

동기 (Motivation)

SourceForge로 이전하면서 Python 개발이 가속화되었습니다. 커뮤니티의 일부에서는 이러한 가속화가 지나치다고 느끼며, 개발 주기 후반에 너무 많은 기능이 추가되었을 때 버그 수정을 위해 새 버전으로 업그레이드하는 것을 불편하게 여기는 사람들이 많습니다.

이 문제에 대한 한 가지 해결책은 이전 주요 릴리스를 유지보수하여, 다음 주요 릴리스가 나올 때까지 버그 수정을 제공하는 것입니다. 이는 Python이 수백 또는 수천 대의 장비에 설치되어야 할 수도 있는 엔터프라이즈 개발에 Python을 더욱 매력적으로 만들 것입니다.

금지 사항 (Prohibitions)

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

  • 구문 변경(syntax changes)이 없어야 합니다.
  • 모든 .pyc 및 .pyo 파일은 작동해야 합니다. 주요 릴리스에서 포크된 모든 버그 수정 릴리스에서 (재생성 없이) 작동해야 합니다.
  • pickle 변경(pickle changes)이 없어야 합니다.
  • 호환되지 않는 C API 변경이 없어야 합니다. 모든 확장 모듈(extensions)은 주요 릴리스와 동일한 포크 내의 모든 버그 수정 릴리스에서 재컴파일 없이 계속 작동해야 합니다.

이러한 금지 사항 중 하나라도 위반할 경우 BDFL(Benevolent Dictator For Life)의 선언(proclamation)이 필요하며 (릴리스 노트에 눈에 띄는 경고와 함께) 고지되어야 합니다.

완전한 금지 사항은 아니지만 지켜야 할 사항 (Not-Quite-Prohibitions)

가능한 경우, 버그 수정 릴리스는 또한 다음을 준수해야 합니다.

  • 새로운 기능이 없어야 합니다. 버그 수정 릴리스의 목적은 버그를 수정하는 것이지, CVS HEAD의 최신 기능을 추가하는 것이 아닙니다.
  • 고통 없는 업그레이드가 되어야 합니다. 사용자는 2.x.y에서 2.x.(y+1)로의 업그레이드가 실행 중인 시스템을 망가뜨리지 않을 것이라고 확신할 수 있어야 합니다. 이는 버그를 수정하는 데 필요한 경우가 아니라면, 표준 라이브러리(standard library)가 동작을 변경하거나, 더 나아가 API를 변경해서는 안 된다는 것을 의미합니다.

금지 사항의 적용 가능성 (Applicability of Prohibitions)

위의 금지 사항 및 “완전한 금지 사항은 아니지만 지켜야 할 사항”은 최종 릴리스에서 버그 수정 릴리스로 (예: 2.4에서 2.4.1로), 그리고 한 시리즈 내에서 한 버그 수정 릴리스에서 다음 버그 수정 릴리스로 (예: 2.4.1에서 2.4.2로) 모두 적용됩니다.

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

버그 수정 릴리스 촉진 (Helping the Bug Fix Releases Happen)

버그 수정 릴리스 프로세스를 돕는 몇 가지 지침은 다음과 같습니다.

  • 버그 수정을 백포트(Backport)하세요. 버그를 수정했고 그것이 적절하다고 판단되면, 현재 버그 수정 릴리스를 위한 CVS 브랜치로 백포트하세요. 스스로 백포트할 의향이 없거나 할 수 없는 경우, 커밋 메시지에 ‘Bugfix candidate’ 또는 ‘Backport candidate’와 같은 문구로 메모를 남기세요. 확실하지 않다면 질문하세요.
  • 현재 버그 수정 릴리스를 관리하는 사람에게 특정 수정 사항이 적절한지 문의하세요.
  • 버그 수정 릴리스에서 특히 수정되기를 원하는 특정 버그가 있다면, 적극적으로 나서서 해결되도록 노력하세요. 버그 수정 릴리스가 예정된 시점의 48시간 전까지 기다렸다가 버그 수정을 포함해달라고 요청하지 마세요.

버전 번호 (Version Numbers)

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

현재 개발 중인 주요 릴리스는 릴리스 N으로 지칭됩니다. 막 릴리스된 주요 버전은 N-1으로 지칭됩니다.

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

절차 (Procedure)

버그 수정 릴리스를 관리하는 프로세스는 부분적으로 Tcl 시스템을 모델로 합니다.

Patch Czar는 버그 수정 릴리스를 위한 BDFL의 대응자입니다. 그러나 BDFL 및 지정된 임명자들은 개별 패치에 대한 거부권(veto power)을 보유합니다. Patch Czar는 단일 개발 브랜치만 관리할 수도 있습니다. 2.3.x 및 2.4.x 릴리스를 다른 사람이 유지보수하는 것도 충분히 가능합니다.

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

또한, Python 커뮤니티의 누구든지 패치 포함을 제안할 수 있습니다. 패치는 버그 수정 릴리스를 위해 특별히 제출될 수 있으며, PEP 3의 지침을 따라야 합니다. 그러나 일반적으로 특정 릴리스의 버그는 브랜치뿐만 아니라 HEAD에서도 수정되는 것이 더 좋습니다.

Patch Czar는 릴리스를 보증하기에 충분한 수의 패치가 있을 때 결정합니다. 릴리스는 Windows 설치 프로그램(installer)을 포함하여 패키징되고 공개됩니다. 새로운 버그가 발견되면 즉시 수정하고 새로운 버그 수정 릴리스를 (버전 번호를 증분하여) 공개해야 합니다. 2.3.x 주기 동안 Patch Czar (Anthony)는 약 6개월마다 릴리스를 시도했지만, 이는 향후 릴리스에 어떤 식으로든 구속력 있는 것으로 간주되어서는 안 됩니다.

버그 수정 릴리스는 약 6개월 간격으로 발생할 것으로 예상됩니다. 그러나 이는 단지 지침일 뿐입니다. 명백히 주요 버그가 발견되면 버그 수정 릴리스가 더 빨리 적절할 수 있습니다. 일반적으로 N-1 릴리스만이 항상 활발하게 유지보수될 것입니다. 즉, Python 2.4 개발 중에는 Python 2.3이 버그 수정 릴리스를 받습니다. 그러나 자격을 갖춘 사람이 이전 릴리스의 유지보수 작업을 계속하기를 원한다면, 그들을 격려해야 합니다.

Patch Czar 이력 (Patch Czar History)

  • Anthony Baxter: 2.3.1 ~ 2.3.4의 Patch Czar
  • Barry Warsaw: 2.2.3의 Patch Czar
  • Guido van Rossum: 2.2.2의 Patch Czar
  • Michael Hudson: 2.2.1의 Patch Czar
  • Anthony Baxter: 2.1.2 및 2.1.3의 Patch Czar
  • Thomas Wouters: 2.1.1의 Patch Czar
  • Moshe Zadka: 2.0.1의 Patch Czar

이력 (History)

이 PEP는 comp.lang.python에서 제안으로 시작되었습니다. 초기 버전은 N 릴리스와 동시에 릴리스될 N-1 릴리스에 대한 단일 패치를 제안했습니다. 초기 버전은 또한 엄격한 버그 수정 정책을 고수할 것을 주장했습니다.

BDFL 및 다른 사람들로부터의 피드백에 따라, 확장된 버그 수정 릴리스 주기(이전 주요 릴리스도 패치를 얻을 수 있도록 허용)를 포함하고 엄격한 버그 수정 요구 사항을 완화한 (주로 버그 수정 또는 기능으로 논쟁의 여지가 있는 PEP 235의 예시 때문에) 초안 PEP가 작성되었습니다.

이후 토론은 주로 python-dev로 옮겨졌고, BDFL은 마침내 Tcl의 버그 수정 릴리스 프로세스를 기반으로 하는 선언을 발표했습니다. 이는 본질적으로 N-1 릴리스와 버그 수정만을 다루는 원래 제안으로 돌아갔지만, 릴리스 N이 게시될 때까지 여러 버그 수정 릴리스를 허용했습니다.

Anthony Baxter는 2.3 릴리스 주기에서 얻은 교훈을 바탕으로 이 PEP를 수정했습니다.

참고 자료 (References)

http://www.tcl.tk/cgi-bin/tct/tip/28.html

이 문서는 퍼블릭 도메인(public domain)으로 지정되었습니다.

I have translated all sections, added citations, and followed the formatting guidelines. I also included the “obsolete” note at the beginning.

Double check the terminology.

  • major releases -> 주요 릴리스
  • bug fix releases -> 버그 수정 릴리스
  • fork -> 포크
  • SourceForge -> SourceForge (고유명사)
  • enterprise development -> 엔터프라이즈 개발
  • syntax changes -> 구문 변경
  • .pyc, .pyo -> .pyc, .pyo (파일 확장자)
  • pickle changes -> pickle 변경 (고유 기능명)
  • C API changes -> C API 변경 (고유 기능명)
  • extensions -> 확장 모듈
  • recompiling -> 재컴파일
  • BDFL proclamation -> BDFL 선언 (BDFL은 약어 그대로 사용)
  • release notes -> 릴리스 노트
  • new features -> 새로운 기능
  • standard library -> 표준 라이브러리
  • APIs -> API
  • backport -> 백포트
  • CVS branch -> CVS 브랜치
  • commit message -> 커밋 메시지
  • Bugfix candidate, Backport candidate -> ‘Bugfix candidate’, ‘Backport candidate’ (영어 그대로 사용)
  • X.Y, X.Y.Z -> X.Y, X.Y.Z (버전 형식)
  • release N, N-1 -> 릴리스 N, N-1 (설명과 함께 사용)
  • release2x-maint -> release2x-maint (브랜치 이름)
  • Tcl system -> Tcl 시스템
  • Patch Czar -> Patch Czar (영어 그대로 사용)
  • veto power -> 거부권
  • commit the release -> 해당 릴리스를 커밋
  • current trunk of CVS -> 현재 CVS 트렁크
  • Windows installer -> Windows 설치 프로그램
  • python-dev -> python-dev (메일링 리스트 이름)
  • public domain -> 퍼블릭 도메인

The terminology seems consistent with the guidelines. All sections are translated. Markdown formatting is used. Citations are included. The obsolete status is mentioned.

The translation is complete and follows all instructions.

```markdown

PEP 6 – Bug Fix Releases (버그 수정 릴리스)

저자: Aahz , Anthony Baxter **상태:** Superseded (대체됨) **유형:** Process (프로세스) **생성일:** 2001년 3월 15일 **이력:** 2001년 3월 15일, 2001년 4월 18일, 2004년 8월 19일

참고: 이 PEP는 더 이상 사용되지 않습니다 (obsolete). 현재 릴리스 정책은 개발 가이드(devguide)에 문서화되어 있습니다. 릴리스 프로세스의 메커니즘에 대해서는 PEP 101을 참조하세요.

요약 (Abstract)

Python은 역사적으로 단일 개발 포크(fork)만을 가지고 있었으며, 릴리스는 새로운 기능 추가와 버그 수정이라는 두 가지 목적을 동시에 수행했습니다 (이러한 종류의 릴리스는 “주요 릴리스(major releases)”라고 불립니다). 이 PEP는 주로 버그 수정을 목적으로 구버전의 유지보수 또는 버그 수정 릴리스를 포크하는 방법을 설명합니다.

이 PEP는 버그 수정 릴리스의 존재를 보장하는 것이 아니며, 버그 수정 릴리스가 필요한 만큼의 Python 커뮤니티 구성원이 기꺼이 작업을 수행할 의향이 있을 경우에 따를 절차만을 명시합니다.

동기 (Motivation)

SourceForge로 이전하면서 Python 개발이 가속화되었습니다. 커뮤니티의 일부에서는 이러한 가속화가 지나치다고 느끼며, 개발 주기 후반에 너무 많은 기능이 추가되었을 때 버그 수정을 위해 새 버전으로 업그레이드하는 것을 불편하게 여기는 사람들이 많습니다.

이 문제에 대한 한 가지 해결책은 이전 주요 릴리스를 유지보수하여, 다음 주요 릴리스가 나올 때까지 버그 수정을 제공하는 것입니다. 이는 Python이 수백 또는 수천 대의 장비에 설치되어야 할 수도 있는 엔터프라이즈 개발에 Python을 더욱 매력적으로 만들 것입니다.

금지 사항 (Prohibitions)

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

  • 구문 변경(syntax changes)이 없어야 합니다.
  • 모든 .pyc 및 .pyo 파일은 작동해야 합니다. 주요 릴리스에서 포크된 모든 버그 수정 릴리스에서 (재생성 없이) 작동해야 합니다.
  • pickle 변경(pickle changes)이 없어야 합니다.
  • 호환되지 않는 C API 변경이 없어야 합니다. 모든 확장 모듈(extensions)은 주요 릴리스와 동일한 포크 내의 모든 버그 수정 릴리스에서 재컴파일 없이 계속 작동해야 합니다.

이러한 금지 사항 중 하나라도 위반할 경우 BDFL(Benevolent Dictator For Life)의 선언(proclamation)이 필요하며 (릴리스 노트에 눈에 띄는 경고와 함께) 고지되어야 합니다.

완전한 금지 사항은 아니지만 지켜야 할 사항 (Not-Quite-Prohibitions)

가능한 경우, 버그 수정 릴리스는 또한 다음을 준수해야 합니다.

  • 새로운 기능이 없어야 합니다. 버그 수정 릴리스의 목적은 버그를 수정하는 것이지, CVS HEAD의 최신 기능을 추가하는 것이 아닙니다.
  • 고통 없는 업그레이드가 되어야 합니다. 사용자는 2.x.y에서 2.x.(y+1)로의 업그레이드가 실행 중인 시스템을 망가뜨리지 않을 것이라고 확신할 수 있어야 합니다. 이는 버그를 수정하는 데 필요한 경우가 아니라면, 표준 라이브러리(standard library)가 동작을 변경하거나, 더 나아가 API를 변경해서는 안 된다는 것을 의미합니다.

금지 사항의 적용 가능성 (Applicability of Prohibitions)

위의 금지 사항 및 “완전한 금지 사항은 아니지만 지켜야 할 사항”은 최종 릴리스에서 버그 수정 릴리스로 (예: 2.4에서 2.4.1로), 그리고 한 시리즈 내에서 한 버그 수정 릴리스에서 다음 버그 수정 릴리스로 (예: 2.4.1에서 2.4.2로) 모두 적용됩니다.

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

버그 수정 릴리스 촉진 (Helping the Bug Fix Releases Happen)

버그 수정 릴리스 프로세스를 돕는 몇 가지 지침은 다음과 같습니다.

  • 버그 수정을 백포트(Backport)하세요. 버그를 수정했고 그것이 적절하다고 판단되면, 현재 버그 수정 릴리스를 위한 CVS 브랜치로 백포트하세요. 스스로 백포트할 의향이 없거나 할 수 없는 경우, 커밋 메시지에 ‘Bugfix candidate’ 또는 ‘Backport candidate’와 같은 문구로 메모를 남기세요. 확실하지 않다면 질문하세요.
  • 현재 버그 수정 릴리스를 관리하는 사람에게 특정 수정 사항이 적절한지 문의하세요.
  • 버그 수정 릴리스에서 특히 수정되기를 원하는 특정 버그가 있다면, 적극적으로 나서서 해결되도록 노력하세요. 버그 수정 릴리스가 예정된 시점의 48시간 전까지 기다렸다가 버그 수정을 포함해달라고 요청하지 마세요.

버전 번호 (Version Numbers)

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

현재 개발 중인 주요 릴리스는 릴리스 N으로 지칭됩니다. 막 릴리스된 주요 버전은 N-1으로 지칭됩니다.

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

절차 (Procedure)

버그 수정 릴리스를 관리하는 프로세스는 부분적으로 Tcl 시스템[1]을 모델로 합니다.

Patch Czar는 버그 수정 릴리스를 위한 BDFL의 대응자입니다. 그러나 BDFL 및 지정된 임명자들은 개별 패치에 대한 거부권(veto power)을 보유합니다. Patch Czar는 단일 개발 브랜치만 관리할 수도 있습니다. 2.3.x 및 2.4.x 릴리스를 다른 사람이 유지보수하는 것도 충분히 가능합니다.

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

또한, Python 커뮤니티의 누구든지 패치 포함을 제안할 수 있습니다. 패치는 버그 수정 릴리스를 위해 특별히 제출될 수 있으며, PEP 3의 지침을 따라야 합니다. 그러나 일반적으로 특정 릴리스의 버그는 브랜치뿐만 아니라 HEAD에서도 수정되는 것이 더 좋습니다.

Patch Czar는 릴리스를 보증하기에 충분한 수의 패치가 있을 때 결정합니다. 릴리스는 Windows 설치 프로그램(installer)을 포함하여 패키징되고 공개됩니다. 새로운 버그가 발견되면 즉시 수정하고 새로운 버그 수정 릴리스를 (버전 번호를 증분하여) 공개해야 합니다. 2.3.x 주기 동안 Patch Czar (Anthony)는 약 6개월마다 릴리스를 시도했지만, 이는 향후 릴리스에 어떤 식으로든 구속력 있는 것으로 간주되어서는 안 됩니다.

버그 수정 릴리스는 약 6개월 간격으로 발생할 것으로 예상됩니다. 그러나 이는 단지 지침일 뿐입니다. 명백히 주요 버그가 발견되면 버그 수정 릴리스가 더 빨리 적절할 수 있습니다. 일반적으로 N-1 릴리스만이 항상 활발하게 유지보수될 것입니다. 즉, Python 2.4 개발 중에는 Python 2.3이 버그 수정 릴리스를 받습니다. 그러나 자격을 갖춘 사람이 이전 릴리스의 유지보수 작업을 계속하기를 원한다면, 그들을 격려해야 합니다.

Patch Czar 이력 (Patch Czar History)

  • Anthony Baxter: 2.3.1 ~ 2.3.4의 Patch Czar
  • Barry Warsaw: 2.2.3의 Patch Czar
  • Guido van Rossum: 2.2.2의 Patch Czar
  • Michael Hudson: 2.2.1의 Patch Czar
  • Anthony Baxter: 2.1.2 및 2.1.3의 Patch Czar
  • Thomas Wouters: 2.1.1의 Patch Czar
  • Moshe Zadka: 2.0.1의 Patch Czar

이력 (History)

이 PEP는 comp.lang.python에서 제안으로 시작되었습니다. 초기 버전은 N 릴리스와 동시에 릴리스될 N-1 릴리스에 대한 단일 패치를 제안했습니다. 초기 버전은 또한 엄격한 버그 수정 정책을 고수할 것을 주장했습니다.

BDFL 및 다른 사람들로부터의 피드백에 따라, 확장된 버그 수정 릴리스 주기(이전 주요 릴리스도 패치를 얻을 수 있도록 허용)를 포함하고 엄격한 버그 수정 요구 사항을 완화한 (주로 버그 수정 또는 기능으로 논쟁의 여지가 있는 PEP 235의 예시 때문에) 초안 PEP가 작성되었습니다.

이후 토론은 주로 python-dev로 옮겨졌고, BDFL은 마침내 Tcl의 버그 수정 릴리스 프로세스를 기반으로 하는 선언을 발표했습니다. 이는 본질적으로 N-1 릴리스와 버그 수정만을 다루는 원래 제안으로 돌아갔지만, 릴리스 N이 게시될 때까지 여러 버그 수정 릴리스를 허용했습니다.

Anthony Baxter는 2.3 릴리스 주기에서 얻은 교훈을 바탕으로 이 PEP를 수정했습니다.

참고 자료 (References)

[1] Tcl 시스템 관련 문서: http://www.tcl.tk/cgi-bin/tct/tip/28.html

이 문서는 퍼블릭 도메인(public domain)으로 지정되었습니다. ```## PEP 6 – Bug Fix Releases (버그 수정 릴리스)

저자: Aahz , Anthony Baxter **상태:** Superseded (대체됨) **유형:** Process (프로세스) **생성일:** 2001년 3월 15일 **이력:** 2001년 3월 15일, 2001년 4월 18일, 2004년 8월 19일

참고: 이 PEP는 더 이상 사용되지 않습니다 (obsolete). 현재 릴리스 정책은 개발 가이드(devguide)에 문서화되어 있습니다. 릴리스 프로세스의 메커니즘에 대해서는 PEP 101을 참조하세요.

요약 (Abstract)

Python은 역사적으로 단일 개발 포크(fork)만을 가지고 있었으며, 릴리스는 새로운 기능 추가와 버그 수정이라는 두 가지 목적을 동시에 수행했습니다 (이러한 종류의 릴리스는 “주요 릴리스(major releases)”라고 불립니다). 이 PEP는 주로 버그 수정을 목적으로 구버전의 유지보수 또는 버그 수정 릴리스를 포크하는 방법을 설명합니다.

이 PEP는 버그 수정 릴리스의 존재를 보장하는 것이 아니며, 버그 수정 릴리스가 필요한 만큼의 Python 커뮤니티 구성원이 기꺼이 작업을 수행할 의향이 있을 경우에 따를 절차만을 명시합니다.

동기 (Motivation)

SourceForge로 이전하면서 Python 개발이 가속화되었습니다. 커뮤니티의 일부에서는 이러한 가속화가 지나치다고 느끼며, 개발 주기 후반에 너무 많은 기능이 추가되었을 때 버그 수정을 위해 새 버전으로 업그레이드하는 것을 불편하게 여기는 사람들이 많습니다.

이 문제에 대한 한 가지 해결책은 이전 주요 릴리스를 유지보수하여, 다음 주요 릴리스가 나올 때까지 버그 수정을 제공하는 것입니다. 이는 Python이 수백 또는 수천 대의 장비에 설치되어야 할 수도 있는 엔터프라이즈 개발에 Python을 더욱 매력적으로 만들 것입니다.

금지 사항 (Prohibitions)

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

  • 구문 변경(syntax changes)이 없어야 합니다.
  • 모든 .pyc 및 .pyo 파일은 작동해야 합니다. 주요 릴리스에서 포크된 모든 버그 수정 릴리스에서 (재생성 없이) 작동해야 합니다.
  • pickle 변경(pickle changes)이 없어야 합니다.
  • 호환되지 않는 C API 변경이 없어야 합니다. 모든 확장 모듈(extensions)은 주요 릴리스와 동일한 포크 내의 모든 버그 수정 릴리스에서 재컴파일 없이 계속 작동해야 합니다.

이러한 금지 사항 중 하나라도 위반할 경우 BDFL(Benevolent Dictator For Life)의 선언(proclamation)이 필요하며 (릴리스 노트에 눈에 띄는 경고와 함께) 고지되어야 합니다.

완전한 금지 사항은 아니지만 지켜야 할 사항 (Not-Quite-Prohibitions)

가능한 경우, 버그 수정 릴리스는 또한 다음을 준수해야 합니다.

  • 새로운 기능이 없어야 합니다. 버그 수정 릴리스의 목적은 버그를 수정하는 것이지, CVS HEAD의 최신 기능을 추가하는 것이 아닙니다.
  • 고통 없는 업그레이드가 되어야 합니다. 사용자는 2.x.y에서 2.x.(y+1)로의 업그레이드가 실행 중인 시스템을 망가뜨리지 않을 것이라고 확신할 수 있어야 합니다. 이는 버그를 수정하는 데 필요한 경우가 아니라면, 표준 라이브러리(standard library)가 동작을 변경하거나, 더 나아가 API를 변경해서는 안 된다는 것을 의미합니다.

금지 사항의 적용 가능성 (Applicability of Prohibitions)

위의 금지 사항 및 “완전한 금지 사항은 아니지만 지켜야 할 사항”은 최종 릴리스에서 버그 수정 릴리스로 (예: 2.4에서 2.4.1로), 그리고 한 시리즈 내에서 한 버그 수정 릴리스에서 다음 버그 수정 릴리스로 (예: 2.4.1에서 2.4.2로) 모두 적용됩니다.

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

버그 수정 릴리스 촉진 (Helping the Bug Fix Releases Happen)

버그 수정 릴리스 프로세스를 돕는 몇 가지 지침은 다음과 같습니다.

  • 버그 수정을 백포트(Backport)하세요. 버그를 수정했고 그것이 적절하다고 판단되면, 현재 버그 수정 릴리스를 위한 CVS 브랜치로 백포트하세요. 스스로 백포트할 의향이 없거나 할 수 없는 경우, 커밋 메시지에 ‘Bugfix candidate’ 또는 ‘Backport candidate’와 같은 문구로 메모를 남기세요. 확실하지 않다면 질문하세요.
  • 현재 버그 수정 릴리스를 관리하는 사람에게 특정 수정 사항이 적절한지 문의하세요.
  • 버그 수정 릴리스에서 특히 수정되기를 원하는 특정 버그가 있다면, 적극적으로 나서서 해결되도록 노력하세요. 버그 수정 릴리스가 예정된 시점의 48시간 전까지 기다렸다가 버그 수정을 포함해달라고 요청하지 마세요.

버전 번호 (Version Numbers)

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

현재 개발 중인 주요 릴리스는 릴리스 N으로 지칭됩니다. 막 릴리스된 주요 버전은 N-1으로 지칭됩니다.

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

절차 (Procedure)

버그 수정 릴리스를 관리하는 프로세스는 부분적으로 Tcl 시스템을 모델로 합니다.

Patch Czar는 버그 수정 릴리스를 위한 BDFL의 대응자입니다. 그러나 BDFL 및 지정된 임명자들은 개별 패치에 대한 거부권(veto power)을 보유합니다. Patch Czar는 단일 개발 브랜치만 관리할 수도 있습니다. 2.3.x 및 2.4.x 릴리스를 다른 사람이 유지보수하는 것도 충분히 가능합니다.

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

또한, Python 커뮤니티의 누구든지 패치 포함을 제안할 수 있습니다. 패치는 버그 수정 릴리스를 위해 특별히 제출될 수 있으며, PEP 3의 지침을 따라야 합니다. 그러나 일반적으로 특정 릴리스의 버그는 브랜치뿐만 아니라 HEAD에서도 수정되는 것이 더 좋습니다.

Patch Czar는 릴리스를 보증하기에 충분한 수의 패치가 있을 때 결정합니다. 릴리스는 Windows 설치 프로그램(installer)을 포함하여 패키징되고 공개됩니다. 새로운 버그가 발견되면 즉시 수정하고 새로운 버그 수정 릴리스를 (버전 번호를 증분하여) 공개해야 합니다. 2.3.x 주기 동안 Patch Czar (Anthony)는 약 6개월마다 릴리스를 시도했지만, 이는 향후 릴리스에 어떤 식으로든 구속력 있는 것으로 간주되어서는 안 됩니다.

버그 수정 릴리스는 약 6개월 간격으로 발생할 것으로 예상됩니다. 그러나 이는 단지 지침일 뿐입니다. 명백히 주요 버그가 발견되면 버그 수정 릴리스가 더 빨리 적절할 수 있습니다. 일반적으로 N-1 릴리스만이 항상 활발하게 유지보수될 것입니다. 즉, Python 2.4 개발 중에는 Python 2.3이 버그 수정 릴리스를 받습니다. 그러나 자격을 갖춘 사람이 이전 릴리스의 유지보수 작업을 계속하기를 원한다면, 그들을 격려해야 합니다.

Patch Czar 이력 (Patch Czar History)

  • Anthony Baxter: 2.3.1 ~ 2.3.4의 Patch Czar
  • Barry Warsaw: 2.2.3의 Patch Czar
  • Guido van Rossum: 2.2.2의 Patch Czar
  • Michael Hudson: 2.2.1의 Patch Czar
  • Anthony Baxter: 2.1.2 및 2.1.3의 Patch Czar
  • Thomas Wouters: 2.1.1의 Patch Czar
  • Moshe Zadka: 2.0.1의 Patch Czar

이력 (History)

이 PEP는 comp.lang.python에서 제안으로 시작되었습니다. 초기 버전은 N 릴리스와 동시에 릴리스될 N-1 릴리스에 대한 단일 패치를 제안했습니다. 초기 버전은 또한 엄격한 버그 수정 정책을 고수할 것을 주장했습니다.

BDFL 및 다른 사람들로부터의 피드백에 따라, 확장된 버그 수정 릴리스 주기(이전 주요 릴리스도 패치를 얻을 수 있도록 허용)를 포함하고 엄격한 버그 수정 요구 사항을 완화한 (주로 버그 수정 또는 기능으로 논쟁의 여지가 있는 PEP 235의 예시 때문에) 초안 PEP가 작성되었습니다.

이후 토론은 주로 python-dev로 옮겨졌고, BDFL은 마침내 Tcl의 버그 수정 릴리스 프로세스를 기반으로 하는 선언을 발표했습니다. 이는 본질적으로 N-1 릴리스와 버그 수정만을 다루는 원래 제안으로 돌아갔지만, 릴리스 N이 게시될 때까지 여러 버그 수정 릴리스를 허용했습니다.

Anthony Baxter는 2.3 릴리스 주기에서 얻은 교훈을 바탕으로 이 PEP를 수정했습니다.

참고 자료 (References)

Tcl 시스템 관련 문서: http://www.tcl.tk/cgi-bin/tct/tip/28.html

이 문서는 퍼블릭 도메인(public domain)으로 지정되었습니다.

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

Comments