PyPy의 릴리스 절차

릴리스 정책

저희는 1년에 몇 차례 안정 릴리스를 만들려고 노력합니다. 이 릴리스는 release-pypy3.5-v2.x 또는 release-pypy3.5-v4.x와 같은 이름의 브랜치에서 배포되며, 각 릴리스 인스턴스에는 예를 들어 release-pypy3.5-v4.0.1과 같은 태그가 붙습니다.

릴리스 버전 번호를 올려야 합니다. 휠에는 major.minor 버전 번호만 표시되므로, 마이크로 릴리스 번호가 올라갔다는 것은 C 확장 휠을 다시 빌드해야 할 만한 변경 사항이 없었다는 뜻입니다. 무엇이 “메이저” 릴리스이고 무엇이 “마이너” 릴리스인지 명확하지 않은 경우가 많은데, 이는 릴리스 매니저가 결정할 수 있습니다.

릴리스 이후에는 버그 수정이 불가피하게 뒤따릅니다. 버그를 수정한 커미터는 그 수정 사항이 릴리스 브랜치에도 반영되도록 할 책임이 있습니다. 그래야 태그가 붙은 버그 수정 릴리스를 만들 수 있으며, 이러한 릴리스는 안정 릴리스보다 더 자주 나오기를 기대합니다.

PyPy 릴리스를 만드는 방법

메타 규칙으로서, 여기 있는 항목들을 트래커에 이슈로 등록해 두면 잊어버리지 않는 데 도움이 될 수 있습니다. 할 일 파일 여러 개를 두는 방법도 효과가 있을 수 있습니다.

릴리스에 해당하는 모든 이슈를 확인하고 우선순위를 정하며, 필요하면 일부는 연기하고 필요에 따라 새 이슈도 만드십시오. 중요한 것은 문서를 최신 상태로 만드는 것입니다!

릴리스 절차

릴리스 브랜치 만들기

이 작업은 새 메이저 버전을 릴리스하는 경우에만 필요합니다. 그렇지 않다면 기존 릴리스 브랜치를 그대로 재사용해도 될 것입니다.

우리는 default를 브랜치로, 또는 그 반대로도 자유롭게 병합할 수 있기를 원합니다. 따라서 병합할 때 버전 번호를 패치하지 않도록 복잡한 절차를 거쳐야 합니다.:

$ git checkout release-pypy2.7-v7.x
$ # edit the version to e.g. 7.0.0-final
$ git commit -a
$ git checkout main
$ # edit the version to 7.1.0-alpha0
$ git commit -a
$ git checkout release-pypy2.7-v7.x
$ git merge main
$ # clear merge conflicts in a way that keeps 7.0.0-final
$ git commit -a

그런 다음, release-pypy3* 브랜치에 대해서도 같은 작업을 해야 합니다

버전을 변경하려면 몇 가지 파일을 수정해야 합니다:

  • module/sys/version.py: PYPY_VERSION은 (7, 3, 10, "final", 0)과 같은 형태여야 하며, rc2의 경우에는 (7, 3, 9, "candidate", 2)와 같은 형태여야 합니다.
  • module/cpyext/include/patchlevel.h: PYPY_VERSION은 최종 릴리스의 경우 “7.3.10”, rc3의 경우 “7.3.10-candidate3”과 같은 형식이어야 합니다.
  • rpython과 pypy 양쪽의 doc/conf.py

저장소에 태그를 추가하십시오. 한 번 커밋한 태그는 절대 변경하지 마십시오. 태그를 변경하면 다운스트림 패키징 워크플로가 깨집니다.

  • 버전 검사를 통과하는지 확인하십시오(이 검사는 version.py와 patchlevel.h가 서로 일치하는지 확인합니다)
  • 태그가 version.py/patchlevel.h의 버전과 일치하는지 확인하십시오. buildbot 실행이 끝난 후에는 태그를 푸시하지 않고도 repackage.sh 스크립트를 실행할 수 있습니다.
  • repackage 스크립트를 실행한 뒤에는 반드시 git push --tags로 태그를 푸시하십시오

기타 단계

  • buildbot에서 RPython 빌드가 실패 없이 통과하는지 확인하십시오

  • module/imp/importing 모듈에 있는 SOABI 번호를 올리는 것이 좋을 수도 있습니다. 이 변경은 여러 가지에 영향을 미치므로 PyPy 커뮤니티가 변경에 동의하는지 반드시 확인하십시오. 휠(wheel)은 이름에 major.minor 릴리스 번호를 사용하므로, cpyext에 호환되지 않는 변경이 있으면 이 번호를 올리십시오.

  • binary-testing CI가 실패 없이 통과하는지, 또는 실패가 있다면 그 원인이 파악되었는지 확인하십시오.

  • 문서 갱신 및 작성

    • pypy/doc/contributor.rst(필요하면 LICENSE도)를 업데이트하십시오. 기여자 목록은 pypy/doc/tool/makecontributor.py가 생성합니다.
    • 릴리스 공지 pypy/doc/release-VERSION.rst를 작성하십시오. 릴리스 공지에는 다운로드 페이지로 바로 가는 링크가 포함되어야 합니다.
    • 새 파일들을 pypy/doc/index-of-release-notes.rst 파일에 추가하십시오.

  • 릴리스 tar-ball 빌드 및 업로드

    • https://buildbot.pypy.org/builders 에 접속하여 해당 브랜치의 빌드를 강제로 실행하십시오. 다음 JIT 바이너리를 빌드해야 합니다: windows-64, linux-32, linux-64, macos_x86_64, macos_arm64, aarch64

    • 빌드가 완료될 때까지 기다린 후 실패한 항목이 없는지 확인하십시오

    • 업로드를 두 번 이상 하지 않도록, 업로드하기 전에 메일링 리스트에 메시지를 보내 테스트를 요청하십시오

    • 다음 단계에서 소스 tarball을 만들 수 있도록 pypy/jitviewer 저장소에 PyPy 릴리스에 해당하는 태그를 추가하십시오.

    • 빌드를 다운로드하고 바이너리를 다시 패키징하십시오. 릴리스 후보 버전에 태그를 붙이고(보통 이 과정을 완료하려면 최소 두 번은 시도해야 하므로 후보로 표시하는 것이 중요합니다), buildbot에서 소스를 다운로드하여 다시 패키징합니다. 이 작업에는 pypy/tool/release에 있는 repackage.sh 스크립트를 사용하면 편리할 수 있습니다.

      소스 “-src.tar.bz2”도 다시 패키징하여 업로드하십시오.

    • 바이너리를 https://buildbot.pypy.org/mirror에 업로드하십시오. pypy/tools/release에 있는 versions.json에 파일을 추가하고 업로드한 다음, 같은 디렉터리에 있는 check_versions.py 파일을 실행합니다. 이 파일은 “github actions” 같은 여러 다운스트림 도구에서 유효한 pypy 다운로드를 찾는 데 사용됩니다. https://downloads.python.org/pypy/가 동기화되기까지 한 시간이 걸립니다. “latest_pypy” 속성에 유의하십시오. 이 속성은 Python 버전별로 지정됩니다. 따라서 새 릴리스가 현재의 latest_pypy를 대체하는 경우(인스턴스로 예를 들면 둘 다 2.7.18인 경우), 이전 버전을 찾아 그 “lastest_pypy”를 “false”로 설정해야 합니다. 그렇지 않으면 check_versions.py(및 여러 도구)가 실패합니다.

  • 막바지 의견과 테스트를 요청하는 메일링 리스트 메시지를 보내십시오

  • 릴리스!

    • repackage.sh 스크립트로 생성하거나 직접 계산한 체크섬 해시로 pypy.org와 다운로드 페이지를 업데이트하십시오.
    • 릴리스 노트와 인덱스에 릴리스 날짜를 반영하십시오
    • pypy.org에 공지를 게시하십시오
    • twitter.com, pypy-dev, python-list, python-announce, python-dev 등에 공지를 보내십시오.

  • 모든 것이 정상이면 릴리스된 버전을 문서화하고, 널리 쓰이는 도구들이 이 버전을 지원하도록 업데이트할 것을 제안하십시오. Github actions가 versions.json을 가져갑니다.