PyPy의 릴리스 프로세스

릴리스 정책

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

릴리스 버전 번호를 올려야 합니다. 마이크로 릴리스 증가는 c-extension 휠을 다시 빌드할 만한 변경 사항이 없었다는 것을 의미합니다. 휠에는 major.minor 버전 번호만 표시되기 때문입니다. 어떤 릴리스가 “major” 릴리스이고 어떤 릴리스가 “minor” 릴리스인지 명확하지 않은 경우가 많으며, 이런 경우에는 릴리스 매니저가 판단할 수 있습니다.

릴리스 이후에는 필연적으로 버그 수정이 발생합니다. 버그를 수정한 커미터는 이 수정 사항이 릴리스 브랜치에 반영되도록 할 책임이 있으며, 이를 통해 태그가 지정된 버그 수정 릴리스를 만들 수 있는데, 이는 안정 릴리스보다 더 자주 이루어지기를 바랍니다.

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 스크립트를 실행할 수 있습니다.
  • 재패키징 스크립트가 실행되면, 반드시 태그를 푸시하십시오: 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

    • 빌드가 완료될 때까지 기다리고, 실패가 없는지 확인하세요

    • 업로드를 두 번 이상 하지 않아도 되도록, 업로드하기 전에 테스트를 요청하는 메일링 리스트 메시지를 보냅니다.

    • pypy/jitviewer 저장소에 pypy 릴리스에 대응하는 태그를 추가하여, 다음 단계에서 소스 tarball을 생성할 수 있도록 합니다

    • 빌드를 다운로드하고, 바이너리를 재패키징합니다. 릴리스 후보(release-candidate) 버전에 태그를 지정하고(보통 이 과정을 완료하는 데 최소 두 번의 시도가 필요하므로 후보로 표시하는 것이 중요합니다) 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” 속성에 유의하세요: 이는 파이썬 버전별로 존재합니다. 따라서 새 릴리스가 현재의 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 액션이 versions.json을 감지합니다.