PEP 102 – Python 마이크로 릴리스 수행하기

Author:

Anthony Baxter <anthony at interlink.com.au>, Barry Warsaw <barry at python.org>, Guido van Rossum <guido at python.org>

Status:

Superseded

Type:

Informational

Created:

09-Jan-2002

Post-History:

Superseded-By:

101

---

Table of Contents

• 대체 안내
• 초록
• 릴리스를 만드는 방법
• 다음은 무엇입니까?
• 최종 릴리스 참고 사항
• Windows 참고 사항
• Copyright

번역·라이선스 안내

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

대체 안내

이 PEP의 할 일 목록은 PEP 101의 목록보다 분량이 훨씬 적어 덜 부담스럽지만, 그것만으로는 정보를 중복해서 두고 그로 인해 사본 중 하나가 낡은 정보가 될 위험을 감수할 이유가 되지 못한다는 것이 드러났습니다. 따라서 이 PEP는 더 이상 유지 관리되지 않으며, 마이크로 릴리스는 PEP 101에서 모두 다룹니다.

초록

Python 릴리스를 만드는 것은 숙련된 릴리스 담당자에게도 최소 반나절의 작업이 필요한 고된 과정입니다. 최근까지 그 부담의 대부분은, 어쩌면 전부가 Guido 본인의 몫이었습니다. 하지만 최근 몇몇 릴리스는 다른 사람들이 수행했으므로, 이 PEP는 Python 버그 수정 릴리스를 만드는 데 필요한 모든 단계를 한곳에 모으고자 합니다.

주요 Python 릴리스 과정은 PEP 101에서 다룹니다. 이 PEP는 PEP 101에서 마이크로 릴리스, 즉 패치 릴리스나 버그 수정 릴리스와 관련된 부분만 남기고 줄인 것입니다.

이 문서는 레시피처럼 구성되어 있으므로, 실제로 인쇄해 두고 항목을 완료할 때마다 하나씩 체크해 나갈 수 있습니다.

릴리스를 만드는 방법

다음은 Python 릴리스를 만들기 위해 거치는 단계입니다. 자동화할 수 있는 부분이 거의 없기 때문에 어떤 단계는 다른 단계보다 더 모호합니다(예: NEWS 항목 작성). 어떤 단계를 보통 특정 전문가가 수행하는 경우에는 그 전문가의 이름을 적어 두었습니다. 그렇지 않은 경우에는 릴리스를 수행하도록 지정된 사람인 릴리스 관리자(RM)가 그 단계를 수행한다고 가정하십시오. 물론 아래에서 RM이 언급되는 거의 모든 곳에서 해당 단계는 BDFL이 수행할 수도 있습니다!

XXX: 병렬로 진행할 수 있는 단계나 다른 단계에 의존하는 단계를 보여 주는 의존성 그래프를 포함해야 합니다.

아래 예시에서는 다음 규칙을 사용합니다. 릴리스 번호는 X.Y.MaA 형식으로 표기합니다. 예를 들어 2.1.2c1은 Python 2.1.2 릴리스 후보 1을 뜻하며, 여기서 “a”는 알파, “b”는 베타, “c”는 릴리스 후보를 나타냅니다. 최종 릴리스에는 CVS에서 “releaseXYZ” 태그를 붙입니다. 마이크로 릴리스는 메이저 릴리스의 유지보수 브랜치에서 만듭니다. 예를 들어 Python 2.1.2는 release21-maint 브랜치에서 만듭니다.

1. python-dev@python.org로 릴리스가 곧 시작된다는 것을 알리는 이메일을 보내십시오.
2. 유지 보수 브랜치로의 체크인을 동결하십시오. 이 시점부터는 RM(또는 정식으로 지정된 그의 대리인, 즉 BDFL인 Guido, 문서를 담당하는 Fred Drake, Windows를 담당하는 Thomas Heller) 외에는 아무도 이 브랜치에 커밋해서는 안 됩니다. RM이 실수를 해서 마지막 순간에 브랜치를 급히 변경해야 하는 상황이 생기면 Fred와 Thomas의 일이 늘어날 수 있습니다. 그러니 이런 일은 피하도록 하십시오!
3. 브랜치에서 Include/patchlevel.h의 두 곳을 수정하여 방금 정한 새 버전 번호를 반영하십시오. PY_VERSION 매크로와, 필요에 따라 PY_VERSION 바로 위에 있는 버전 하위 부분 매크로 중 하나 또는 여러 개를 변경해야 합니다.
4. Misc/RPM/python-2.3.spec의 “%define version” 줄을 위에서 PY_VERSION에 설정한 것과 같은 문자열로 변경하십시오. 예::

   %define version 2.3.1
   

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

5. Python의 버전 번호를 바꾸는 경우(예: Python 2.1.1에서 Python 2.1.2로), README 파일도 갱신해야 합니다. 이 파일 맨 위에는 자신이 어떤 버전인지 알리는 큰 배너가 있습니다. 새 알파나 베타 릴리스를 내는 것뿐이라면 이 작업을 하지 마십시오. 하지만 새 마이크로, 마이너, 메이저 릴리스를 내는 경우라면 /반드시/ 하십시오.
6. 릴리스 번호를 참조하는 곳이 여러 군데 있으므로 LICENSE(라이선스) 파일도 변경해야 합니다. README 파일과 마찬가지로, 새 마이크로, 마이너, 메이저 릴리스에서는 이 부분들을 변경해야 합니다.

   LICENSE(라이선스) 파일에는 Python의 법적 유산을 설명하는 표가 있습니다. 지금 만들고 있는 X.Y.Z 릴리스에 대한 항목을 이 표에 추가해야 합니다. CVS 트렁크에 있는 LICENSE(라이선스) 파일의 이 표도 갱신해야 합니다.

7. 연도가 바뀌면 README와 LICENSE(라이선스) 파일을 비롯한 여러 곳에서 저작권 문구를 갱신해야 합니다.
8. Windows 빌드를 위해서는 파일을 추가로 더 갱신해야 합니다.

   PCbuild/BUILDno.txt에는 Windows 빌드 번호가 들어 있습니다. 이 번호를 바꾸는 방법은 이 파일에 있는 설명을 참고하십시오. 프로젝트 파일 PCbuild/pythoncore.dsp를 저장하면 PCbuild/pythoncore.dsp도 변경됩니다.

   PCbuild/python20.wse는 Windows 설치 프로그램의 버전 리소스(설치 프로그램 .exe를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택하면 표시됩니다)를 설정하며, Python 버전 번호도 담고 있습니다.

   (버전 2.3.2 이전에는 PC/python_nt.rc를 직접 편집해야 했지만, 이제 이 단계는 빌드 과정에서 자동으로 처리됩니다.)

9. 절차를 시작한 뒤 다음으로 할 가장 중요한 일은 Misc/NEWS 파일을 갱신하는 것입니다. Thomas가 Windows 릴리스를 하려면 이 파일이 필요하며, 그는 늦게까지 깨어 있는 것을 좋아합니다. 이 단계는 꽤 지루할 수 있으므로 브랜치를 만든 직후, 또는 브랜치를 만들기 전에라도 바로 시작하는 것이 가장 좋습니다. 빠를수록 좋습니다(다만 거듭 말하지만, 릴리스가 나올 때까지 새로 체크인되는 내용을 계속 주시하십시오!)

   이번 릴리스에서 새로 추가된 상위 수준 항목을 추가하십시오. 예를 들어 2.2a3을 릴리스한다면, 파일 맨 위에 “What’s new in Python 2.2a3”을 설명하는 절이 있어야 합니다. 그 뒤에는 “What’s new in Python 2.2a2”라는 제목의 절이 이어집니다.

   개발자들이 트렁크에 새 기능을 추가하면서 NEWS 파일도 그에 맞게 갱신했기를 /바랄/ 뿐이라는 점에 유의하십시오. 확신할 수는 없으므로 다시 한번 확인하십시오. Unix만 아는 사람이라면 Windows 관련 변경 사항은 Thomas에게, Mac 관련 변경 사항은 Jack Jansen에게 확인하는 것이 도움이 됩니다.

   다음 명령이 도움이 될 것입니다(다만 -r 태그는 올바른 것으로 바꾸십시오!):

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

   즉, 이전 릴리스부터 지금까지의 cvs 로그 항목을 모두 출력하는 것입니다. 그런 다음 news.txt 파일을 샅샅이 훑어보며 NEWS에 추가할 만한 흥미로운 내용을 찾으면 됩니다.

10. NEWS 변경 사항을 유지 보수 브랜치에 체크인하십시오. 이 파일의 릴리스 날짜를 갱신하는 것을 잊기 쉽습니다!
11. IDLE의 NEWS.txt에 대한 변경 사항을 체크인하십시오. Lib/idlelib/NEWS.txt의 헤더를 릴리스 버전과 날짜에 맞게 갱신하십시오. 이에 맞춰 Lib/idlelib/idlever.py의 IDLE 버전도 갱신하십시오.

11. 릴리스 절차가 시작되면 PEP 101의 설명에 따라 문서를 빌드하여 python.org에 게시해야 합니다.

    정리 단계에서 문서 변경 사항을 트렁크에서 브랜치로 병합하는 일과 브랜치의 모든 변경 사항을 브랜치에서 트렁크로 병합하는 일을 모두 Fred가 담당한다는 점에 유의하십시오. 기본적으로 Doc/ 안에 있는 것이라면 Fred가 처리합니다.

12. 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에서 풀어낸 것과 버전 번호가 같은지 확인해야 합니다.

    Thomas는 이 파일을 starship에 업로드합니다. 그런 다음 Windows 실행 파일의 위치와 MD5 체크섬이 담긴 알림을 RM에게 보냅니다.

    Thomas가 Windows 실행 파일을 만드는 과정에서 브랜치에 커밋이 몇 개 더 생길 수 있다는 점에 유의하십시오. Thomas는 Windows 전용 변경 사항을 트렁크에서 브랜치로, 그리고 브랜치에서 트렁크로 병합하는 일을 담당합니다.

13. Sean은 Red Hat 마법을 부려 RPM 묶음을 생성합니다. 그는 이 파일들을 python.org에 업로드합니다. 그런 다음 RPM의 위치와 MD5 체크섬이 담긴 알림을 RM에게 보냅니다.
14. 빌드할 시간입니다!

    이제 소스 타르볼을 빌드할 준비가 되었습니다. 먼저 브랜치의 작업 디렉터리로 cd 하십시오. 예: % cd …/python-22a3

15. 이 디렉터리에서 “cvs update”를 실행하십시오. -A 플래그는 절대 넣지 마십시오!

    “M” 파일은 보이지 않아야 하지만, “P” 및/또는 “U” 파일은 여러 개 보일 수 있습니다. 즉, 작업 디렉터리에 커밋하지 않은 변경 사항이 있어서는 안 되지만, Fred나 Thomas의 막바지 변경 사항 일부를 받아 올 수는 있습니다.

16. 이제 “rXYMaZ”와 같은 심볼릭 이름으로 브랜치에 태그를 붙이십시오. 예: r212

    % cvs tag r212
    

    Python CVS 트리의 python/dist/src 하위 디렉터리에만 태그를 붙이도록 주의하십시오!

17. 중립적인 디렉터리, 즉 브랜치를 깨끗한 새 상태로 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
    

18. 타르볼을 생성하십시오. tar 명령에 ‘z’ 옵션을 사용하지 않는다는 점에 유의하십시오. 1) 저희가 아는 한 이 옵션은 GNU tar에서만 지원되고, 2) 압축 수준을 최대로 올릴 것인데 이는 지원되는 옵션이 아니기 때문입니다. tar.gz와 tar.bz2 형식을 모두 생성합니다. 후자가 약 6분의 1 더 작기 때문입니다.

    % 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
    

19. 방금 만든 tgz 파일과 tar.bz2 파일의 MD5 체크섬을 계산하십시오.

    % md5sum Python-2.1.2.tgz
    

    md5sum 프로그램이 없다면 Tools/scripts/md5sum.py 파일에 있는 Python 대체 프로그램을 사용할 수 있다는 점에 유의하십시오.

20. 각 파일에 대해 GPG 키를 생성하십시오.

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

21. 이제 방금 만든 tarball을 검사하는 매우 중요한 단계를 수행해야 합니다. 완전히 깨끗한 새 빌드가 회귀 테스트를 통과하는지 확인하기 위한 단계입니다. 수행할 최선의 절차는 다음과 같습니다.:

    % cd /tmp
    % tar zxvf ~/Python-2.1.2.tgz
    % cd Python-2.1.2
    % ls
    (Do things look reasonable?)
    % ./configure
    (Loads of configure output)
    % make test
    (Do all the expected tests pass?)
    

    테스트가 통과하면 tarball에 문제가 없다고 안심해도 됩니다. 일부 테스트가 실패하거나, 새로 압축을 푼 디렉터리에서 무엇이든 이상해 보인다면 지금 바로 중단하고 무엇이 문제인지 알아내는 것이 좋습니다.

22. tgz 파일과 exe 파일을 creosote.python.org에 업로드해야 합니다. 이 단계는 네트워크 대역폭에 따라 오래 걸릴 수 있습니다. 두 파일을 자신의 컴퓨터에서 creosote로 scp하십시오.
23. 기다리는 동안 공지를 포함하도록 웹 페이지를 손보기 시작할 수 있습니다.
    1. 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
       

    2. 파일의 내용을 편집하십시오. 보통은 X.Ya(Z-1)을 X.YaZ로 일괄 치환하면 됩니다. 하지만 “What’s New?” 섹션은 따로 고민해야 합니다.
    3. Misc/NEWS 파일을 python.org용 X.Y.Z 디렉터리의 NEWS.txt로 복사하십시오. 이 파일에는 이 Python 버전의 이전 릴리스 이후 Python에 적용된 변경 사항의 “전모”가 담겨 있습니다.
    4. 앞에서 만든 .asc GPG 서명도 이곳에 복사하십시오.
    5. 또한 MD5 체크섬을 갱신하십시오.
    6. “make” 또는 “make install”을 실행하여 웹 페이지를 미리 보십시오(단, 이 릴리스를 위한 새 디렉터리를 만든 경우에 한합니다!).
    7. 마찬가지로 ../index.ht 파일, 즉 python.org 홈페이지를 편집하십시오. Big Blue Announcement Block에서 새 버전에 관한 문단을 맨 위로 옮기고 “Python X.YaZ is out”이라는 문구를 굵게 표시하십시오. 내용을 편집하고 로컬에서 미리 보되, 아직 “make install”은 하지 마십시오!
24. 이제 creosote로의 scp가 끝나기를 기다립니다. 다 디 다, 다 디 덤, 흠, 흠, 덤 디 덤.
25. 그 작업이 끝나면 creosote.python.org에 접속하여 모든 파일을 그곳의 제자리로 옮겨야 합니다. 저희 정책은 모든 Python 버전이 각자의 디렉터리를 가지되, 각 디렉터리에는 여러 릴리스가 들어 있을 수 있다는 것입니다. 저희는 모든 이전 릴리스를 보관하며, 새 릴리스가 나오면 이전 릴리스를 “prev” 하위 디렉터리로 옮깁니다.

    따라서 Python-2.2a2.exe와 Python-2.2a2.tgz가 들어 있는 “2.2”라는 디렉터리가 있고, 그 안에 Python-2.2a1.exe와 Python-2.2a1.tgz가 들어 있는 “prev” 하위 디렉터리가 있습니다.

    그러면…

    1. creosote에서 ~ftp/pub/python/X.Y로 cd하십시오. 필요하면 이 디렉터리를 만드십시오.
    2. 이전 릴리스 파일을 “prev”라는 디렉터리로 옮기십시오. 필요하면 이 디렉터리를 만드십시오(디렉터리에 g+ws 비트가 설정되어 있는지 확인하십시오). 새 Python 버전의 첫 번째 알파 릴리스라면 이 단계를 건너뛰십시오.
    3. .tgz 파일과 .exe 파일을 이 디렉터리로 옮기십시오. 모든 사용자가 읽을 수 있는지 확인하십시오. 또한 그룹 쓰기 권한이 있어야 하며, 그룹 소유자는 webmaster여야 합니다.
    4. 파일들의 md5sum을 확인하여 손상 없이 업로드되었는지 확인하십시오.
26. 필요하다면 X.Y/bugs.ht 파일도 수정하십시오. 이 단계에서는 BDFL의 의견을 구하는 것이 가장 좋습니다.
27. 상위 디렉터리(즉, 웹 페이지 계층 구조의 루트)로 올라가서 그곳에서 “make install”을 실행하십시오. 이제 릴리스가 공개되었습니다!
28. 이제 메일링 리스트에 보낼 공지를 작성할 차례입니다. 자동화할 수 있는 부분이 많지 않아서 이 단계는 명확하게 정해진 방법이 없습니다. Guido가 이전에 작성한 공지 중 하나를 템플릿으로 사용해도 되지만, 내용은 반드시 수정하십시오!

    공지가 준비되면 다음 주소로 보내십시오:

    python-list@python.org
    python-announce@python.org
    python-dev@python.org
    

29. 릴리스에 관한 SourceForge 뉴스 항목을 게시하십시오. 프로젝트의 “메뉴 바”에서 “News” 링크를 선택하고, News에 들어가면 “Submit” 링크를 선택하십시오. Subject 상자에 적절한 제목(예: “Python 2.2c1 released” :-))을 입력하고, Details 상자에 내용(최소한 www.python.org의 릴리스 URL과 이번 릴리스에 만족한다는 내용은 포함)을 추가한 다음 SUBMIT 버튼을 누르십시오.

    오래된 뉴스 항목은 자유롭게 삭제해도 됩니다.

이제 정리 작업을 할 차례입니다. 이 단계들은 매우 중요합니다!

1. PY_VERSION 문자열이 “X.YaZ+”와 같은 형태가 되도록 Include/patchlevel.h 파일을 수정하십시오. 끝에 붙은 ‘+’는 trunk에서 개발이 계속 진행된다는 것을 나타낸다는 점에 유의하십시오. 예를 들어, 해당 줄은 다음과 같아야 합니다:

   #define PY_VERSION              "2.1.2+"
   

   다른 PY_ 버전 매크로에도 올바른 값이 들어 있는지 확인하십시오. 이 변경 사항을 커밋하십시오.

2. 아주 신중을 기하고 싶다면 릴리스를 완전히 깨끗한 상태에서 테스트하십시오. 여기에는 www.python.org에서 tarball을 내려받는 것도 포함됩니다.
3. md5 체크섬이 일치하는지 확인하십시오. 그런 다음 tarball의 압축을 풀고 깨끗한 상태에서 make test를 실행하십시오.

   % make distclean
   % ./configure
   % make test
   

   회귀 테스트 스위트가 통과하는지 확인하기 위한 것입니다. 통과하지 않는다면 어딘가에서 실수한 것입니다!

5단계 …

검증하십시오! 이 단계는 4단계와 병행할 수 있습니다. 사용자가 된 것처럼 python.org에서 파일을 내려받고, 그것으로 Python을 빌드해 보십시오. 이 단계는 간과하기가 너무 쉬우며, 실제로 여러 차례 쓸모없는 릴리스 파일이 나온 적이 있습니다. 한 번은 전반적인 서버 문제로 모든 파일이 알 수 없는 이유로 손상되었고, 한 번은 소스 tarball이 잘못 빌드되었으며, SF의 파일 업로드 과정에서 파일이 잘린 일도 한 번이 아니었습니다. 이 밖에도 여러 일이 있었습니다.

다음은 무엇입니까?

기뻐하십시오. 한잔하십시오. 즐거운 시간을 보내십시오. 이것과 같은 PEP를 작성하십시오. 아니면 Guido를 본받아 휴가를 떠나십시오.

여러분은 방금 Python 릴리스를 만들었습니다!

사실 한 단계가 더 남아 있습니다. 브랜치의 소유권을 Jack Jansen에게 넘겨야 합니다. 이는 이제부터 그가 브랜치에 커밋하는 일을 맡게 된다는 뜻일 뿐입니다. 그는 이를 이용해 MacOS 버전을 빌드할 것입니다. 그는 www.python.org의 안내 페이지에 병합해야 할 Mac 릴리스 관련 정보를 여러분에게 보낼 수도 있습니다. 작업을 마치면 그는 브랜치에 “rX.YaZ-mac”과 같은 태그를 붙일 것입니다. 또한 Mac 관련 변경 사항을 트렁크에 다시 병합하는 일도 그가 맡습니다.

최종 릴리스 참고 사항

모든 메이저 릴리스의 최종 릴리스(예: Python 2.2 final)에는 특별한 요구 사항이 있는데, 특히 가장 오래 쓰이는 릴리스 가운데 하나가 되기 때문입니다(즉, 베타는 몇 주 이상 가지 않지만 최종 릴리스는 몇 년씩 쓰일 수 있습니다!).

이러한 이유로 Windows, Mac, 소스라는 세 가지 주요 릴리스 사이에 더 긴밀한 조율이 이루어지기를 바랍니다. Windows 릴리스와 소스 릴리스는 각 릴리스 봇이 서로 가까이 있다는 이점을 누립니다. 하지만 Mac 봇인 Jack Jansen과는 6시간의 시차가 있습니다. 그래서 최종 릴리스의 릴리스 절차에 다음과 같은 추가 단계를 더합니다:

1. Jack이 승인할 때까지, 또는 우리의 인내심이 바닥날 때까지 최종 릴리스를 보류하십시오 <wink>.

새 버그 수정 릴리스를 내놓을 때에는 python.org 사이트도 몇 군데 손봐야 합니다.

2. 문서는 doc/<version>/에 설치해야 합니다.
3. doc/<previous-minor-release>/index.ht에서 새 버전의 문서로 가는 링크를 추가하십시오.
4. 이전의 모든 doc/<old-release>/index.ht 파일은 새 버전의 문서를 가리키도록 갱신해야 합니다.
5. 검색 엔진이 이전 버전의 문서를 크롤링하지 못하도록 /robots.txt를 수정해야 합니다.

Windows 참고 사항

Windows에는 GUI 설치 프로그램이 있고, 여러 Windows 버전에는 각기 “특별한 제약”이 있으며, Windows 설치 프로그램에는 미리 컴파일된 “외부” 바이너리(Tcl/Tk, expat 등)도 들어 있습니다. 그래서 Windows 테스트는 지루하지만 꼭 필요합니다.

Thomas는 설치 프로그램을 업로드하는 동시에 그 설치 프로그램으로 Python을 두 번 설치합니다. 한 번은 설치 프로그램이 제안하는 기본 디렉터리에 설치하고, 그다음에는 이름에 공백이 들어간 디렉터리에 설치합니다. 각 설치본마다 DOS 창에서 전체 회귀 테스트 스위트를 -0을 붙인 경우와 붙이지 않은 경우 모두 실행합니다.

또한 시작 -> 메뉴 -> Python 그룹 아래에 만들어진 모든 바로 가기를 실행해 봅니다. 이렇게 IDLE을 실행해 볼 때는 도움말 -> Python Documentation이 동작하는지 확인해야 합니다. 이렇게 pydoc(시작 메뉴의 “Module Docs” 항목)을 실행해 볼 때는 “Start Browser” 버튼이 동작하는지 확인하고, 임의의 모듈을 검색할 수 있는지(Thomas는 “random”을 사용합니다 <wink>), 이어서 “go to selected” 버튼이 동작하는지 확인하십시오.

여기서 잘못될 수 있는 일이 얼마나 많은지 놀라울 정도이며, 마지막 순간의 체크인이 이 중 하나를 망가뜨리는 일이 얼마나 잦은지는 더욱 놀랍습니다. 여러분이 “Windows 전문가”라면, Windows에서 정기적으로 테스트하는 사람은 아마 여러분뿐일 것이고 Windows는 그야말로 엉망이라는 점을 명심하십시오.

위의 모든 과정을 적어도 Win9x 계열 하나와 NT/2000/XP 계열 하나에서 반복하십시오. NT/2000/XP에서는 관리자 계정과 (Power User가 아닌) 일반 User 계정 모두로 시도해 보십시오.

위의 5단계(릴리스 매체 검증)와 관련해서는, 릴리스 파일을 내려받을 수 있게 될 무렵이면 Thomas는 대개 자신이 업로드한 설치 프로그램으로 이미 많은 Windows 테스트를 실행한 뒤이므로, 5단계에서는 보통 내려받은 파일과 자신이 업로드한 파일을 바이트 단위로 전부 비교하는 것(Windows 셸을 사용한다면 “fc /b”) 외에는 아무것도 하지 않습니다.

Copyright

This document has been placed in the public domain.