Rust 릴리스 프로세스
Rust는 현재 다음과 같이 릴리스됩니다:
start-release.py 스크립트에 대한 참고 사항
프로덕션 환경과의 상호작용이 필요한 릴리스 프로세스 단계는 start-release.py 스크립트를 통해 실행됩니다. 이 스크립트는 프로그램 설치와 로컬 환경 설정을 요구하며, 설정 과정을 안내해 줍니다.
스크립트를 처음 실행할 때(또는 사전 요구 사항이 변경되었을 때)는 모든 것이 올바르게 설정될 때까지 스크립트를 여러 번 실행해야 합니다.
start-release.py는 항상 백그라운드에서 CI 작업을 시작합니다. 작업이 언제 끝나는지 알려면 로그를 지켜봐야 합니다. 빌드가 끝나면 로그에 다음과 같은 줄이 나타납니다:
Phase complete: UPLOAD_ARTIFACTS State: SUCCEEDED
stable 버전 번호 올리기 (전 주 금요일)
src/version의 버전 번호를 올리는 PR을 여십시오. 이 PR을 r+ rollup=never로 처리합니다(직접 승인).
rollup=never로 표시해야 합니다. 롤업에 첫 번째 PR이 아닌 상태로 들어가면 해당 롤업의 다른 풀 리퀘스트들이 이전 릴리스와 잘못 연결되기 때문입니다.
이는 사실상 beta 브랜치가 갈라지는 시점입니다 – beta가 승격될 때, 이 버전 번호 변경 PR 바로 직전에 병합된 PR을 기준으로 삼게 됩니다.
브랜치 승격 (월요일)
두 승격 모두 월요일에 이루어져야 합니다. 두 PR을 동시에 열 수 있지만, (사전 릴리스 테스트 기간을 최대화하기 위해) stable 승격을 먼저 병합하는 것을 우선시하십시오.
beta 및 stable 브랜치의 기준점 업데이트
rust-lang/release-team 저장소1에서 다음 명령을 실행하십시오:
./scripts/start-release.py update-rust-branches
start-release.py는 백그라운드에서 작업을 시작하며, 브랜치가 업데이트되기 전에 스크립트가 종료된다는 점을 기억하십시오. 진행하기 전에 백그라운드 작업이 언제 끝나는지 로그를 지켜보십시오.
stable PR
새 stable 브랜치를 대상으로 rust-lang/rust에 다음 변경 사항을 담은 PR을 보내십시오:
-
릴리스 노트를 최신 사본으로 업데이트하십시오:
-
릴리스 노트 PR이 병합된 경우:
git checkout origin/HEAD -- RELEASES.md -
그렇지 않으면, 대기 중인 릴리스 노트 PR에서
RELEASES.md를 수동으로 복사하십시오
-
-
src/ci/channel을stable로 업데이트하십시오
브랜치 업데이트 전에 병합되지 않은 beta 백포트가 있는지도 확인하고, 이를 stable PR에 체리픽하십시오:
- beta 브랜치를 대상으로 하는 PR 목록.
- beta 백포트로 승인된 PR 목록.
- beta 백포트로 지명된 PR 목록. 이 목록에 있는 PR은 승인된 것이 아니므로, 관련 팀과 후속 협의를 통해 처리 방법을 결정해야 합니다.
r+ rollup=never p=1000으로 PR을 직접 승인하십시오.
사전 릴리스 테스트 시간을 최대화하기 위해 이 PR을 가능한 한 빨리 병합해야 한다는 점에 유의하십시오. 다른 PR이 bors에 의해 테스트 중이고 CI가 곧 끝나지 않을 것 같다면(이 부분은 판단이 필요합니다), 해당 PR로 이동하여 다음 댓글을 입력함으로써 stable 릴리스 PR에 우선순위를 “양보“할 수 있습니다:
@bors yield
beta PR
새 beta 브랜치를 대상으로 rust-lang/rust에 다음 변경 사항을 담은 PR을 보내십시오:
-
이 명령을 실행하고 그 출력만을 담은 별도의 커밋을 생성하십시오:
./x.py run replace-version-placeholder -
src/ci/channel을beta로 업데이트합니다
r+ rollup=never p=10으로 PR을 직접 승인하십시오.
dev-static 환경에 사전 릴리스를 게시하십시오
stable PR이 병합된 후 사전 릴리스를 시작해야 합니다. rust-lang/release-team 저장소1에서 다음 명령을 실행하십시오:
./scripts/start-release.py publish-rust-dev-stable YYYY-MM-DD
YYYY-MM-DD를 릴리스 날짜(목요일)로 교체해야 합니다.
기본 브랜치 bootstrap 업데이트 및 Crater (화요일)
이 단계는 새 beta가 릴리스된 이후에만 수행할 수 있습니다. beta의 릴리스 프로세스는 매일 UTC 00:00에 자동으로 진행되므로, beta PR이 그 이후에 병합되었다면 하루 더 기다려야 합니다. rustup으로 설치해 봄으로써 beta가 릴리스되었는지 확인할 수 있습니다.
기본 브랜치에 다음 내용으로 PR을 보내십시오:
-
방금 병합된 beta 브랜치 PR에서
replace-version-placeholder를 실행한 커밋을 체리픽하십시오. 이 도구를 다시 실행하지 마십시오. 기본 브랜치에는 분기된 beta에 포함되지 않은 다른 안정화 작업들이 있을 수 있으며, 이는 현재 릴리스에 귀속되지 않을 수 있기 때문입니다. -
어제 만든 beta로 bootstrap 컴파일러를 업데이트하려면 다음을 실행하십시오:
./x.py run src/tools/bump-stage0 -
bootstrap및not(bootstrap)조건부 컴파일 속성에 대한 참조를 제거하십시오. ripgrep을 설치하고 다음 명령을 실행하면 그 모두를 찾을 수 있습니다:rg '#!?\[.*\(bootstrap' -t rust -t toml(
#[]와#![]모두에 대한) 일반 지침은 다음과 같습니다:#[cfg(bootstrap)]로 표시된 항목은 모두 제거하십시오.#[cfg(not(bootstrap))]속성은 모두 제거하되 해당 항목은 유지하십시오.#[cfg_attr(bootstrap, $attr)]속성은 모두 제거하되 해당 항목은 유지하십시오.#[cfg_attr(not(bootstrap), doc="$doc")]는 모두 관련 문서 블록(또는 새 문서 블록) 내의$doc으로 교체하십시오.#[cfg_attr(not(bootstrap), $attr)]는 모두#[$attr]로 교체하십시오.
PR이
cfg(bootstrap)을 추가하고 beta PR과 기본 브랜치 bootstrap 업데이트 사이에 병합된 경우,rg호출 결과에 해당 항목들이 나타나더라도 제거할 필요는 없다는 점에 유의하십시오. 이를 처리하는 가장 쉬운 방법은 어차피 변경한 다음 CI가 실패를 보여주도록 두는 것입니다. -
코드베이스에 영향을 미치는 새로운 경고나 Clippy 린트가 없는지 확인하십시오:
./x clippy ci
새 beta가 나온 이 시점에 다음 릴리스 주기를 위한 crater 실행을 시작해 두는 것도 좋은 방법입니다. 이는 다음 주기의 일환으로 실행이 시작되기까지 걸릴 시간에 따라, 결과가 트리아지되기까지의 지연을 며칠에서 몇 주까지 줄일 수 있습니다.
이는 crater 실행을 시작하는 것일 뿐이며, 실제로 crater 실행을 트리아지하고 처리하는 것은 릴리스를 진행하는 사람의 책임이 아니라는 점에 유의하십시오. 시간이 부족하다면 이 단계는 건너뛸 수 있으며, 다음 주기의 crater 실행을 담당하는 사람이 이를 시작할 것입니다.
- crater 실행을 시작하는 방법은 릴리스 crater 실행 장을 참고하십시오
릴리스 당일(목요일)
릴리스를 진행할 시간을 정하십시오. 릴리스가 진행되는 시점을 결정하는 것은 전적으로 여러분의 몫이니, 여러분에게 가장 적합한 시간을 선택하십시오. 유일한 제약 조건은, 릴리스 과정이 릴리스 당일(UTC 기준) 내에 시작되고 끝나야 한다는 것입니다.
소셜 미디어 코디네이터(현재 Mara)에게 시간을 알려서, 그녀가 프로젝트의 소셜 미디어 채널에 릴리스를 게시할 준비를 할 수 있도록 하십시오.
2024년 9월 기준으로 릴리스는 완료하는 데 75분에서 90분이 걸리므로, 계획한 시간에 맞출 수 있도록 릴리스 과정을 충분히 일찍 시작하십시오.
릴리스를 시작하려면 rust-lang/release-team 저장소1에서 다음 명령을 실행하십시오:
./scripts/start-release.py publish-rust-prod-stable
이 명령은 프로덕션 환경을 대상으로 promote-release를 호출하는 백그라운드 작업을 시작하며, 그 로그를 확인하는 방법에 대한 안내를 보여줄 것입니다.
릴리스 과정이 완료되면, 블로그 게시물 PR을 병합하고 Mara에게 알려 소셜 미디어에 릴리스를 발표하도록 하십시오. 마지막으로, 여러분의 성공을 만끽하십시오 🎉
beta stage0 업데이트 (금요일)
게시한 stable 릴리스로 stage0을 업데이트하는 풀 리퀘스트를 beta 브랜치로 보내십시오:
./x run src/tools/bump-stage0
부록: stable 사전 릴리스 재빌드
문제가 발생하여 stable 아티팩트를 재빌드해야 하는 경우, rust-lang/rust 저장소의 stable 브랜치에 풀 리퀘스트를 병합하십시오. 커밋이 병합되면 AWS로 인증한 후 rust-lang/release-team 저장소에서 다음 명령을 실행하십시오:
./scripts/start-release.py publish-rust-dev-stable-rebuild
이미 게시한 사전 릴리스 공지도 블로그와 internals에서 새 정보로 업데이트해야 합니다.