PEP 102 – 파이썬 마이크로 릴리스 만들기

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에서 완전히 다루어집니다.

초록

파이썬 릴리스를 만드는 것은 숙련된 릴리스 담당자에게조차 최소 반나절의 작업이 필요한 고된 과정입니다. 최근까지는 그 부담의 전부는 아니더라도 대부분을 귀도 본인이 짊어졌습니다. 하지만 최근 몇몇 릴리스는 다른 사람들에 의해 수행되었으므로, 이 PEP는 파이썬 버그 수정 릴리스를 만드는 데 필요한 모든 단계를 한곳에 모으고자 합니다.

주요 파이썬 릴리스 과정은 PEP 101에서 다루어지며, 이 PEP는 마이크로 릴리스, 즉 패치 또는 버그 수정 릴리스와 관련된 부분만 추려낸 PEP 101에 불과합니다.

이것은 레시피 형태로 구성되어 있어서 실제로 출력하여 항목을 완료할 때마다 체크할 수 있습니다.

릴리스를 만드는 방법

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

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

아래 예제에서는 다음과 같은 관례를 사용합니다. 릴리스 번호가 주어지는 경우, 이는 X.Y.MaA 형식이며, 예를 들어 Python 2.1.2 릴리스 후보 1의 경우 2.1.2c1과 같이 표기하고, 여기서 “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 매크로와, 그 바로 위에 있는 버전 하위 부분 매크로 중 필요에 따라 하나 이상을 변경해야 합니다.
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 파일도 업데이트했기를 /바랄/ 뿐이라는 점에 유의하십시오. 확신할 수는 없으니 다시 한번 확인하십시오. 유닉스에 익숙한 사람이라면, 윈도우 쪽 변경 사항은 Thomas에게, 맥 쪽 변경 사항은 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에 업로드합니다. 그런 다음 그는 RM에게 Windows 실행 파일의 위치와 MD5 체크섬이 포함된 통지를 보냅니다.

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

13. Sean은 자신의 Red Hat 마법을 부려 RPM 세트를 생성합니다. 그는 이 파일들을 python.org에 업로드합니다. 그런 다음 그는 RM에게 RPM의 위치와 MD5 체크섬이 포함된 통지를 보냅니다.
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 두 형식을 모두 생성하는데, 후자가 약 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
    

19. 방금 생성한 tgz 및 tar.bz2 파일의 MD5 체크섬을 계산하십시오.

    % md5sum Python-2.1.2.tgz
    

    md5sum 프로그램이 없다면 Tools/scripts/md5sum.py 파일에 파이썬으로 작성된 대체 프로그램이 있다는 점에 유의하십시오.

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로 복사하십시오. 이 파일에는 이번 버전의 파이썬이 이전 릴리스 이후 변경된 내용이 “전부 상세히” 담겨 있습니다.
    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” 하위 디렉터리로 옮기고 보관합니다.

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

    자…

    1. creosote에서 ~ftp/pub/python/X.Y로 이동하고, 필요하면 새로 만듭니다.
    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. Include/patchlevel.h 파일을 편집하여 PY_VERSION 문자열이 “X.YaZ+”와 같은 형태가 되도록 하십시오. 트렁크가 앞으로 개발을 계속 진행할 것임을 나타내는 끝부분의 ‘+’에 유의하십시오. 예를 들어 해당 줄은 다음과 같이 보여야 합니다:

   #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을 빌드해 보십시오. 이 단계는 간과하기 너무나 쉬우며, 실제로 여러 번 쓸모없는 릴리스 파일이 나온 적이 있습니다. 한 번은 일반적인 서버 문제로 모든 파일이 알 수 없게 손상된 적이 있었고, 한 번은 소스 타르볼이 잘못 빌드된 적이 있었으며, 여러 번 SF의 파일 업로드 과정에서 파일이 잘려나간 적도 있었습니다.

다음은 무엇입니까?

기뻐하십시오. 마시십시오. 즐거운 시간을 보내십시오. 이것과 같은 PEP를 작성하십시오. 아니면 귀도처럼 휴가를 떠나십시오.

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

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

최종 릴리스 노트

예를 들어 Python 2.2 최종판과 같은 모든 주요 릴리스의 최종판은 특별한 요구 사항을 가지는데, 이는 특히 그것이 가장 오래 유지되는 릴리스 중 하나이기 때문입니다(즉, 베타는 몇 주 이상 지속되지 않지만, 최종 릴리스는 몇 년 동안 지속될 수 있습니다!).

이러한 이유로 우리는 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 문서가 작동하는지 확인해야 합니다. 이 방식으로 pydoc(시작 메뉴의 “Module Docs” 항목)을 시도할 때는 “Start Browser” 버튼이 작동하는지 확인하고, 임의의 모듈을 검색할 수 있는지(Thomas는 “random”을 사용합니다 <wink>) 확인한 다음, “go to selected” 버튼이 작동하는지 확인하십시오.

여기서 얼마나 많은 것이 잘못될 수 있는지 놀라울 정도이며, 막판 커밋이 이런 것들 중 하나를 얼마나 자주 망가뜨리는지는 더욱 놀랍습니다. 만약 당신이 “Windows 전문가”라면, 당신이 Windows에서 정기적으로 테스트하는 유일한 사람일 가능성이 높다는 점과 Windows는 그야말로 엉망이라는 점을 명심하십시오.

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

위의 5단계(릴리스 미디어 검증)와 관련해서는, 릴리스 파일이 다운로드 준비가 될 때쯤이면 Thomas가 이미 업로드한 설치 프로그램에 대해 많은 Windows 테스트를 수행한 상태이므로, 그는 보통 5단계에서 다운로드한 파일과 업로드한 파일을 전체 바이트 비교(Windows 셸을 사용하는 경우 “fc /b”)하는 것 외에는 별다른 작업을 하지 않습니다.

Copyright

This document has been placed in the public domain.