[Superseded] PEP 102 - Doing Python Micro Releases

원문 링크: PEP 102 - Doing Python Micro Releases

상태: Superseded

유형: Informational

작성일: 09-Jan-2002

PEP 102 – Python 마이크로 릴리스(Micro Releases) 수행하기

• 작성자: Anthony Baxter, Barry Warsaw, Guido van Rossum
• 상태: Superseded (대체됨)
• 유형: Informational (정보성)
• 생성일: 2002년 1월 9일
• 대체 문서: PEP 101로 대체됨

대체 알림 (Replacement Note)

이 PEP의 할 일 목록은 PEP 101의 목록보다 훨씬 간단하지만, 정보 중복을 정당화할 만큼 충분하지 않으며, 이로 인해 사본 중 하나가 오래될 위험이 있습니다. 따라서 이 PEP는 더 이상 유지 관리되지 않으며, 마이크로 릴리스(micro releases)에 대한 내용은 PEP 101에서 전적으로 다루고 있습니다.

개요 (Abstract)

Python 릴리스(release)를 생성하는 것은 숙련된 릴리스 담당자에게도 최소 반나절의 작업 시간이 소요되는 고된 과정입니다. 최근까지도 이 부담의 대부분은 Guido van Rossum 본인이 감당했습니다. 그러나 최근 여러 릴리스가 다른 사람들에 의해 수행되었으므로, 이 PEP는 Python 버그 수정 릴리스(bugfix release)를 생성하는 데 필요한 모든 단계를 한곳에 모으려고 시도합니다.

주요 Python 릴리스 프로세스는 PEP 101에서 다루고 있으며, 이 PEP는 마이크로 릴리스(micro releases), 즉 패치(patch) 또는 버그 수정 릴리스(bug fix releases)와 관련된 부분만 포함하도록 PEP 101을 축소한 버전입니다. 이 문서는 레시피(recipe) 형식으로 구성되어 있으며, 실제로 인쇄하여 단계를 완료할 때마다 항목을 확인할 수 있습니다.

릴리스를 만드는 방법 (How to Make A Release)

다음은 Python 릴리스를 생성하는 단계입니다. 일부 단계는 자동화할 수 있는 부분이 거의 없기 때문에 (예: NEWS 항목 작성) 다른 단계보다 모호합니다. 일반적으로 “전문가(An Expert)”가 수행하는 단계의 경우 해당 전문가의 이름이 명시되어 있습니다. 그렇지 않은 경우, 해당 단계는 릴리스 담당자(Release Manager, RM)가 수행한다고 가정합니다. RM이 언급된 거의 모든 곳에서 BDFL(Benevolent Dictator For Life)인 Guido van Rossum 또한 이 단계를 수행할 수 있습니다.

주의: 병렬로 수행할 수 있는 단계 또는 다른 단계에 의존하는 단계를 설명하기 위해 의존성 그래프(dependency graph)를 포함해야 합니다.

아래 예시에서는 다음 규칙을 사용합니다. 릴리스 번호가 주어질 경우, X.Y.MaA 형식입니다. 예를 들어, Python 2.1.2 릴리스 후보 1은 2.1.2c1이며, 여기서 “a”는 알파(alpha), “b”는 베타(beta), “c”는 릴리스 후보(release candidate)를 의미합니다. 최종 릴리스는 CVS에서 “releaseXYZ”로 태그됩니다. 마이크로 릴리스는 주요 릴리스의 유지보수 브랜치(maintenance branch)에서 생성됩니다. 예를 들어, Python 2.1.2는 release21-maint 브랜치에서 생성됩니다.

1. 릴리스 시작 알림 및 체크인 동결: 릴리스가 시작될 것임을 알리는 이메일을 python-dev@python.org로 보냅니다. 유지보수 브랜치에 대한 체크인(check-ins)을 동결합니다. 이 시점에서는 RM 외에는 누구도 해당 브랜치에 커밋(commit)할 수 없습니다 (BDFL인 Guido, 문서 담당 Fred Drake, Windows 담당 Thomas Heller와 같은 정식으로 지정된 대리인 제외). RM이 실수하여 브랜치에 마지막 순간의 변경이 필요하면, Fred와 Thomas에게 추가 작업이 발생할 수 있으므로 이를 피해야 합니다.

2. 버전 번호 업데이트: 브랜치에서 Include/patchlevel.h 파일의 두 곳을 수정하여 새로 생성한 버전 번호를 반영합니다. PY_VERSION 매크로와 PY_VERSION 바로 위에 있는 버전 하위 파트 매크로를 적절하게 변경해야 합니다. Misc/RPM/python-2.3.spec 파일의 "%define version" 줄을 위에서 변경한 PY_VERSION과 동일한 문자열로 변경합니다.

   %define version 2.3.1
   

   또한 %define release 줄이 '1pydotorg'가 아니라면 이 값으로 재설정하는 것이 좋습니다.

3. README 및 LICENSE 파일 업데이트: Python의 버전 번호를 변경하는 경우 (예: Python 2.1.1에서 Python 2.1.2로), 상단에 ID를 선언하는 README 파일도 업데이트해야 합니다. 새로운 알파 또는 베타 릴리스를 출시하는 경우에는 이 작업을 하지 않지만, 새로운 마이크로, 마이너 또는 메이저 릴리스를 출시하는 경우에는 반드시 수행해야 합니다. LICENSE 파일도 릴리스 번호에 대한 여러 참조 때문에 변경해야 합니다. README 파일과 마찬가지로, LICENSE 파일의 변경은 새로운 마이크로, 마이너 또는 메이저 릴리스에 필요합니다.

4. LICENSE 파일의 법적 출처 테이블 업데이트: LICENSE 파일에는 Python의 법적 출처를 설명하는 표가 포함되어 있습니다. 현재 만들고 있는 X.Y.Z 릴리스에 대한 항목을 추가해야 합니다. CVS 트렁크(trunk)의 LICENSE 파일에도 이 표를 업데이트해야 합니다.

5. 저작권 및 Windows 빌드 파일 업데이트: 연도가 변경될 때, README 및 LICENSE 파일을 포함한 여러 위치의 저작권 문구(copyright legends)를 업데이트해야 합니다. Windows 빌드의 경우, 추가 파일들을 업데이트해야 합니다.
   • PCbuild/BUILDno.txt: Windows 빌드 번호를 포함하며, 파일 내 지침에 따라 변경해야 합니다.
   • PCbuild/pythoncore.dsp: 프로젝트 파일 PCbuild/pythoncore.dsp를 저장하면 이 파일도 변경됩니다.
   • PCbuild/python20.wse: Windows 설치 프로그램의 버전 리소스(installer .exe 파일을 마우스 오른쪽 버튼으로 클릭하고 “속성(Properties)”을 선택할 때 표시됨)를 설정하며, Python 버전 번호도 포함합니다.
   • (버전 2.3.2 이전에는 PC/python_nt.rc를 수동으로 편집해야 했지만, 이 단계는 이제 빌드 프로세스에 의해 자동화됩니다).

6. Misc/NEWS 파일 업데이트: 프로세스를 시작한 후 가장 중요한 다음 작업은 Misc/NEWS 파일을 업데이트하는 것입니다. Thomas는 Windows 릴리스를 위해 이것이 필요하며, 그는 밤늦게까지 일하는 것을 좋아합니다. 이 단계는 상당히 지루할 수 있으므로, 브랜치를 만든 직후 또는 브랜치를 만들기 전에도 즉시 착수하는 것이 가장 좋습니다. 빠를수록 좋지만 (릴리스가 만들어질 때까지 새로운 체크인을 계속 확인하세요!).

7. 새 릴리스 항목 추가: 이 릴리스에 새로 추가된 상위 수준 항목들을 추가합니다. 예를 들어, 2.2a3을 릴리스하는 경우, 파일 상단에 “What’s new in Python 2.2a3”이라는 섹션이 있어야 하며, 그 다음에는 “What’s new in Python 2.2a2”라는 섹션이 이어져야 합니다.

8. NEWS 파일 변경 사항 확인: 개발자들이 트렁크에 새로운 기능을 추가할 때 NEWS 파일도 그에 맞게 업데이트했기를 바라지만, 확실하지 않으므로 다시 확인해야 합니다. Unix 사용자의 경우, Windows 변경 사항에 대해서는 Thomas에게, Mac 변경 사항에 대해서는 Jack Jansen에게 확인하는 것이 도움이 됩니다. 이 명령어는 도움이 될 것입니다 (하지만 올바른 -r 태그를 대체하세요!):

   % cvs log -rr22a1: | python Tools/scripts/logmerge.py > /tmp/news.txt
   

   이는 이전 릴리스부터 현재까지의 모든 cvs log 항목을 출력하는 것입니다. 그런 다음 news.txt 파일을 훑어보면서 NEWS에 추가할 흥미로운 내용을 찾을 수 있습니다.

9. IDLE NEWS.txt 및 버전 업데이트: NEWS 변경 사항을 유지보수 브랜치에 체크인합니다. 이 파일의 릴리스 날짜를 업데이트하는 것을 잊기 쉽습니다! IDLE의 NEWS.txt에 대한 변경 사항을 체크인합니다. Lib/idlelib/NEWS.txt 파일의 헤더를 릴리스 버전 및 날짜에 맞게 업데이트합니다. Lib/idlelib/idlever.py 파일의 IDLE 버전을 일치하도록 업데이트합니다.

10. 문서 빌드 및 게시: 릴리스 프로세스가 시작되면, PEP 101의 지침에 따라 문서를 빌드하고 python.org에 게시해야 합니다. Fred는 트렁크에서 브랜치로 문서 변경 사항을 병합하고, 정리 단계에서 브랜치의 모든 변경 사항을 트렁크로 병합하는 두 가지 책임을 모두 담당합니다. 기본적으로 Doc/에 있는 모든 것은 Fred가 처리합니다.

11. Windows 릴리스 빌드 (Thomas): Thomas는 MSVC 6.0 SP5로 모든 것을 컴파일하고 python23.chm 파일을 src/chm 디렉토리로 이동합니다. 그런 다음 Wise Installation System으로 설치 프로그램 실행 파일이 생성됩니다. 설치 프로그램에는 MSVCRT.DLL 및 MSVCIRT.DLL 파일에 MSVC 6.0 런타임이 포함됩니다. 이 파일들을 설치 프로그램이 빌드되는 시스템 디렉토리에서 가져오면 문제가 발생하므로, 반드시 MSVC SP5 CD에 포함된 VCREDIST.EXE 재배포 가능 패키지에서 가져와야 합니다. VCREDIST.EXE는 Winzip으로 압축을 풀어야 하며, Wise Installation System에서 디렉토리를 묻습니다. 설치 프로그램을 빌드한 후에는 Winzip으로 열고, MS DLL을 다시 추출하여 VCREDIST.EXE에서 압축을 푼 DLL과 동일한 버전 번호인지 확인해야 합니다. Thomas는 이 파일을 스타십(starship)에 업로드합니다. 그런 다음 RM에게 Windows 실행 파일의 위치와 MD5 체크섬을 포함한 알림을 보냅니다. Thomas의 Windows 실행 파일 생성 과정에서 브랜치에 몇 가지 커밋이 더 발생할 수 있습니다. Thomas는 Windows 관련 변경 사항을 트렁크에서 브랜치로, 그리고 브랜치에서 트렁크로 병합하는 책임을 맡습니다.

12. RPM 생성 및 업로드 (Sean): Sean은 그의 Red Hat 마법을 수행하여 RPM 세트를 생성합니다. 그는 이 파일들을 python.org에 업로드합니다. 그런 다음 RM에게 RPM의 위치와 MD5 체크섬을 포함한 알림을 보냅니다. 이제 빌드할 시간입니다!

13. 소스 타볼(tarball) 빌드 준비: 이제 소스 타볼을 빌드할 준비가 되었습니다. 먼저 브랜치의 작업 디렉토리로 이동합니다. 예:

    % cd …/python-22a3
    

    이 디렉토리에서 “cvs update”를 수행합니다. -A 플래그를 포함하지 마세요! “M” 파일은 보이지 않아야 하지만, 여러 “P” 및/또는 “U” 파일은 볼 수 있습니다. 즉, 작업 디렉토리에 커밋되지 않은 변경 사항이 없어야 하지만, Fred나 Thomas의 마지막 순간 변경 사항을 가져올 수 있습니다.

14. 브랜치 태그 지정: 이제 “rXYMaZ”와 같은 심볼릭 이름으로 브랜치에 태그를 지정합니다. 예: r212

    % cvs tag r212
    

    Python CVS 트리의 python/dist/src 하위 디렉토리에만 태그를 지정해야 합니다!

15. 태그된 브랜치 export: 중립적인 디렉토리, 즉 브랜치의 새롭고 깨끗한 cvs export를 수행할 수 있는 디렉토리로 변경합니다. 이 위치에 “Python-X.Y.M”이라는 이름의 새 디렉토리를 생성할 것입니다. 태그가 지정된 브랜치를 CVS export합니다.

    % cd ~
    % cvs -d cvs.sf.net:/cvsroot/python export -rr212 \
    -d Python-2.1.2 python/dist/src
    

16. 타볼 생성: 타볼을 생성합니다. tar 명령어에 -z 옵션을 사용하지 않는 이유는 1) 우리가 아는 한 GNU tar에서만 지원되고, 2) 압축 수준을 최대로 설정할 것이며, 이는 지원되는 옵션이 아니기 때문입니다. tar.gz와 tar.bz2 형식을 모두 생성하는데, 후자가 약 1/6 더 작습니다.

    % tar -cf - Python-2.1.2 | gzip -9 > Python-2.1.2.tgz
    % tar -cf - Python-2.1.2 | bzip2 -9 > Python-2.1.2.tar.bz2
    

17. MD5 체크섬 계산: 방금 생성한 tgz 및 tar.bz2 파일의 MD5 체크섬을 계산합니다.

    % md5sum Python-2.1.2.tgz
    

    md5sum 프로그램이 없는 경우, Tools/scripts/md5sum.py 파일에 Python 대체 프로그램이 있습니다.

18. GPG 키 생성: 각 파일에 대한 GPG 키를 생성합니다.

    % gpg -ba Python-2.1.2.tgz
    % gpg -ba Python-2.1.2.tar.bz2
    % gpg -ba Python-2.1.2.exe
    

19. 타볼 회귀 테스트: 이제 방금 생성한 타볼을 확인하여 완전히 깨끗하고, 순수한 빌드가 회귀 테스트(regression test)를 통과하는지 확인하는 매우 중요한 단계를 수행해야 합니다. 다음은 수행할 최선의 단계입니다.

    % cd /tmp
    % tar zxvf ~/Python-2.1.2.tgz
    % cd Python-2.1.2
    % ls (내용이 합리적으로 보이는가?)
    % ./configure (수많은 configure 출력)
    % make test (예상된 모든 테스트가 통과하는가?)
    

    테스트가 통과하면 타볼이 정상이라고 확신할 수 있습니다. 일부 테스트가 실패하거나 새로 압축을 푼 디렉토리의 다른 부분이 이상해 보이면 즉시 작업을 중단하고 문제를 파악해야 합니다.

20. 파일 업로드 및 웹 페이지 수정 준비: tgz 및 exe 파일을 creosote.python.org에 업로드해야 합니다. 이 단계는 네트워크 대역폭에 따라 오랜 시간이 걸릴 수 있습니다. scp를 사용하여 두 파일을 자신의 머신에서 creosote로 전송합니다. 기다리는 동안 웹 페이지를 조정하여 공지 사항을 포함할 수 있습니다.

21. python.org 웹 페이지 업데이트: python.org 웹 사이트 CVS 트리의 최상단에 X.Y.Z 릴리스를 위한 하위 디렉토리를 생성합니다. 이전 패치 릴리스의 하위 디렉토리를 복사할 수도 있지만, X.Y.Z/CVS 디렉토리를 삭제하고 “cvs add X.Y.Z”를 수행해야 합니다. 예를 들면 다음과 같습니다.

    % cd .../pydotorg
    % cp -r 2.2.2 2.2.3
    % rm -rf 2.2.3/CVS
    % cvs add 2.2.3
    % cd 2.2.3
    

    내용을 위해 파일을 편집합니다. 일반적으로 X.Ya(Z-1)을 X.YaZ로 전역적으로 대체할 수 있습니다. 그러나 “What’s New?” 섹션에 대해서는 고려해야 합니다. Misc/NEWS 파일을 python.org의 X.Y.Z 디렉토리에 NEWS.txt로 복사합니다. 이 파일은 이 Python 버전의 이전 릴리스 이후 변경 사항에 대한 “전체 내용”을 포함합니다. 이전에 생성한 .asc GPG 서명도 여기에 복사합니다. 또한 MD5 체크섬을 업데이트합니다. “make” 또는 “make install”을 수행하여 웹 페이지를 미리 봅니다 (이 릴리스를 위해 새 디렉토리를 생성한 경우에만!). 마찬가지로 ../index.ht 파일, 즉 python.org 홈페이지를 편집합니다. “Big Blue Announcement Block”에서 새 버전의 단락을 맨 위로 이동하고 “Python X.YaZ is out” 문구를 굵게 표시합니다. 내용을 편집하고 로컬에서 미리 보지만, 아직 “make install”을 수행하지 마세요!

22. creosote 파일 배치 및 권한 설정: 이제 creosote로의 scp가 완료되기를 기다립니다. 완료되면 creosote.python.org로 이동하여 모든 파일을 제자리에 옮겨야 합니다. 우리의 정책은 각 Python 버전이 자체 디렉토리를 가지지만, 각 디렉토리에는 여러 릴리스가 포함될 수 있다는 것입니다. 우리는 모든 이전 릴리스를 유지하며, 새 릴리스가 있을 때 “prev” 하위 디렉토리로 이동합니다. 예를 들어, “2.2”라는 디렉토리에는 Python-2.2a2.exe와 Python-2.2a2.tgz가 포함되어 있으며, Python-2.2a1.exe와 Python-2.2a1.tgz를 포함하는 “prev” 하위 디렉토리도 있습니다. 따라서… creosote에서 필요한 경우 ~ftp/pub/python/X.Y로 cd합니다. 이전 릴리스 파일을 “prev”라는 디렉토리로 이동합니다 (필요한 경우 디렉토리를 생성하고 g+ws 비트가 설정되어 있는지 확인합니다). 이것이 새로운 Python 버전의 첫 번째 알파 릴리스인 경우 이 단계를 건너뜁니다. .tgz 파일과 .exe 파일을 이 디렉토리로 이동합니다. 이 파일들이 모든 사용자가 읽을 수 있도록 (world readable) 하고, 그룹 쓰기 가능(group writable)하며, webmaster가 그룹 소유자로 설정되어 있는지 확인합니다. 파일의 md5sum을 확인하여 손상되지 않고 업로드되었는지 확인합니다.

23. 릴리스 활성화: 필요한 경우 X.Y/bugs.ht 파일을 편집합니다. 이 단계에서는 BDFL의 의견을 듣는 것이 가장 좋습니다. 상위 디렉토리 (즉, 웹 페이지 계층의 루트)로 이동하여 거기서 “make install”을 수행합니다. 이제 릴리스가 활성화되었습니다!

24. 메일링 리스트 공지 작성 및 발송: 이제 메일링 리스트(mailing lists)용 공지 사항을 작성할 시간입니다. 이 부분은 자동화할 수 있는 것이 많지 않기 때문에 모호한 부분입니다. Guido의 이전 공지 사항 중 하나를 템플릿으로 사용할 수 있지만, 내용을 편집해야 합니다! 공지 사항이 준비되면 다음 주소로 보냅니다.
    • python-list@python.org
    • python-announce@python.org
    • python-dev@python.org

25. SourceForge 뉴스 항목 제출: 릴리스에 대한 SourceForge 뉴스 항목을 보냅니다. 프로젝트의 “메뉴 바”에서 “News” 링크를 선택하고, News에서 “Submit” 링크를 선택합니다. 적절한 제목 (예: “Python 2.2c1 released” :-)을 “Subject” 상자에 입력하고, “Details” 상자에 일부 텍스트 (최소한 www.python.org의 릴리스 URL과 릴리스에 만족한다는 사실을 포함)를 추가한 다음 “SUBMIT” 버튼을 클릭합니다. 오래된 뉴스 항목은 자유롭게 제거하세요.

26. Include/patchlevel.h 정리 및 커밋: 이제 정리할 시간입니다. 이 단계들은 매우 중요합니다! Include/patchlevel.h 파일을 편집하여 PY_VERSION 문자열이 “X.YaZ+”와 같이 표시되도록 합니다. 후행 ‘+’는 트렁크가 개발을 계속 진행할 것임을 나타냅니다. 예: 해당 줄은 다음과 같아야 합니다.

    #define PY_VERSION "2.1.2+"
    

    다른 PY_ 버전 매크로에 올바른 값이 포함되어 있는지 확인합니다. 이 변경 사항을 커밋합니다.

27. 최종 릴리스 테스트 (철저한 확인): 극도로 조심하는 사람들을 위해, 릴리스에 대한 완전히 깨끗한 테스트를 수행합니다. 여기에는 www.python.org에서 타볼을 다운로드하는 것이 포함됩니다. md5 체크섬이 일치하는지 확인합니다. 그런 다음 타볼의 압축을 풀고 깨끗한 make test를 수행합니다.

    % make distclean
    % ./configure
    % make test
    

    회귀 테스트 스위트(regression test suite)가 통과하는지 확인하기 위함입니다. 만약 통과하지 못하면 어딘가에서 잘못된 것입니다!

28. 릴리스 미디어 확인: 확인! 이것은 4단계와 교차될 수 있습니다. 사용자라고 가정하고 python.org에서 파일을 다운로드하여 Python을 빌드합니다. 이 단계는 너무 쉽게 간과될 수 있으며, 여러 번 쓸모없는 릴리스 파일을 만든 적이 있습니다. 한 번은 일반적인 서버 문제로 인해 모든 파일이 알 수 없는 방식으로 손상되었고, 한 번은 소스 타볼이 잘못 빌드되었으며, SourceForge에서 파일 업로드 과정에서 파일이 여러 번 잘린 적도 있습니다.

다음은 무엇인가? (What Next?)

기뻐하십시오. 마시고. 즐기십시오. 이와 같은 PEP를 작성하십시오. 또는 Guido처럼 휴가를 떠나십시오. 방금 Python 릴리스를 만들었습니다!

사실, 한 가지 단계가 더 있습니다. 브랜치의 소유권을 Jack Jansen에게 넘겨주어야 합니다. 이것은 이제 그가 브랜치에 커밋을 하는 책임을 지게 된다는 것을 의미합니다. 그는 이것을 사용하여 MacOS 버전을 빌드할 것입니다. 그는 www.python.org의 정보 페이지에 병합되어야 할 Mac 릴리스에 대한 정보를 보낼 수 있습니다. 그가 작업을 마치면 “rX.YaZ-mac”과 같은 태그로 브랜치에 태그를 지정할 것입니다. 그는 또한 Mac 관련 변경 사항을 트렁크로 다시 병합하는 책임도 맡을 것입니다.

최종 릴리스 노트 (Final Release Notes)

모든 주요 릴리스의 최종 릴리스(예: Python 2.2 final)는 특별한 요구 사항을 가집니다. 특히, 가장 오래 유지될 릴리스 중 하나이기 때문입니다 (베타는 몇 주 이상 지속되지 않지만, 최종 릴리스는 몇 년 동안 지속될 수 있습니다!). 이러한 이유로 우리는 Windows, Mac, 소스의 세 가지 주요 릴리스 간에 더 높은 조율을 원합니다. Windows 및 소스 릴리스는 각 릴리스 봇(release-bots)의 긴밀한 근접성으로부터 이점을 얻습니다. 하지만 Mac 봇인 Jack Jansen은 6시간 떨어져 있습니다. 따라서 최종 릴리스의 릴리스 프로세스에 이 추가 단계를 추가합니다. Jack이 승인하거나 우리가 인내심을 잃을 때까지 최종 릴리스를 보류합니다 .

새로운 버그 수정 릴리스가 발행될 때 python.org 사이트도 약간의 조정이 필요합니다. 문서는 doc/<version>/에 설치되어야 합니다. doc/<previous-minor-release>/index.ht에서 새 버전의 문서로 링크를 추가합니다. 모든 이전 doc/<old-release>/index.ht 파일은 새 버전의 문서를 가리키도록 업데이트되어야 합니다. /robots.txt는 이전 버전의 문서가 검색 엔진에 의해 크롤링되는 것을 방지하기 위해 수정되어야 합니다.

Windows 관련 참고사항 (Windows Notes)

Windows에는 GUI 설치 프로그램이 있으며, 다양한 Windows 버전에는 “특별한 제한 사항”이 있고, Windows 설치 프로그램에는 미리 컴파일된 “외부(foreign)” 바이너리 (Tcl/Tk, expat 등)도 포함되어 있습니다. 따라서 Windows 테스트는 지루하지만 매우 필수적입니다.

설치 프로그램을 업로드하는 동시에 Thomas는 그것으로부터 Python을 두 번 설치합니다. 한 번은 설치 프로그램이 제안하는 기본 디렉토리에, 다른 한 번은 이름에 공백이 포함된 디렉토리에 설치합니다. 각 설치에 대해 그는 DOS 박스에서 전체 회귀 스위트(regression suite)를 실행하며, -0 옵션 사용 여부와 관계없이 모두 실행합니다. 그는 또한 시작 -> 메뉴 -> Python 그룹 아래에 생성된 모든 바로가기를 시도합니다. 이 방식으로 IDLE을 시도할 때는 도움말 -> Python 문서(Help -> Python Documentation)가 작동하는지 확인해야 합니다. 이 방식으로 pydoc을 시도할 때 ( “모듈 문서” 시작 메뉴 항목), “브라우저 시작(Start Browser)” 버튼이 작동하는지 확인하고, 임의의 모듈 (Thomas는 “random”을 사용합니다 )을 검색할 수 있는지, 그리고 "선택한 항목으로 이동(go to selected)" 버튼이 작동하는지 확인해야 합니다. 여기서 얼마나 많은 것이 잘못될 수 있는지 놀랍고, 마지막 순간 체크인이 이러한 것들 중 하나를 얼마나 자주 망가뜨리는지 더욱 놀랍습니다. 만약 당신이 "Windows 괴짜"라면, 당신이 Windows에서 일상적으로 테스트하는 유일한 사람일 가능성이 높고, Windows는 단순히 엉망진창이라는 것을 명심하십시오.

위의 모든 단계를 적어도 하나의 Win9x 버전과 하나의 NT/2000/XP 버전에서 반복합니다. NT/2000/XP에서는 관리자 계정과 일반 사용자 계정 (Power User 아님) 모두에서 시도합니다.

위의 5단계 (릴리스 미디어 확인)와 관련하여, 릴리스 파일이 다운로드 준비가 될 무렵 Thomas는 그가 업로드한 설치 프로그램에 대해 이미 많은 Windows 테스트를 실행했으므로, 일반적으로 5단계에 대해서는 다운로드된 파일과 그가 업로드한 파일 간의 전체 바이트 비교 (“fc /b” (Windows 셸을 사용하는 경우)) 외에는 아무것도 하지 않습니다.

저작권 (Copyright)

이 문서는 퍼블릭 도메인에 공개되었습니다.

출처: https://github.com/python/peps/blob/main/peps/pep-0102.rst 최종 수정일: 2025-02-01 08:55:40 GMT

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