Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

릴리스 노트 준비

이 문서는 Rust 릴리스를 알리는 릴리스 노트(저수준 변경 로그)와 블로그 게시물(고수준 변경 로그)을 준비하는 절차를 다룹니다.

자동화/커뮤니티: 1단계: PR 또는 이슈에 릴리스 노트 검토용 레이블이 붙습니다

이 단계는 rust-lang/rust의 relnotes, relnotes-perf, finished-final-comment-period 레이블에 대해 진행되며 triagebot이 관리합니다(구현).

이 단계는 이슈/PR이 병합되거나 닫힐 때가 아니라 레이블이 붙을 때 진행된다는 점에 유의하십시오. (FIXME: 특히 추적 이슈의 경우, 필요할 때 작성자가 relnotes 이슈를 볼 가능성을 높이려면 이 단계를 닫히는 시점으로 옮겨야 하지 않겠습니까?)

자동화/커뮤니티: 2단계: 블로그 게시물 또는 릴리스 노트 문구를 제안합니다

레이블이 지정되면 “Tracking issue for release notes of #xxxx: $original pr title”(#xxxx의 릴리스 노트에 대한 추적 이슈: $original pr title)라는 제목으로 새 이슈가 자동으로 생성됩니다. 이 이슈에는 relnotes + relnotes-tracking-issue 레이블이 붙습니다.

해당 영역을 담당하는 Rust 팀 및/또는 PR을 작성한 기여자는 이 이슈에서 릴리스 노트 문구를 제안할 수 있습니다(또한 제안해야 합니다). 이 이슈에는 릴리스 노트 내용(RELNOTES.md에 들어갈 내용)과 블로그 내용을 위한 코드 블록이 들어 있습니다.

문구는 코드 블록에서 직접 수정하는 것이 가장 좋지만, 권한이 없다면 스레드에서 논의해도 되며 그 내용은 나중에 릴리스 팀이 반영합니다.

릴리스 노트 문구는 이후 단계에서 자동으로 가져가므로, 가능하면 이 목록에 있는 제목을 사용해야 합니다.

  • 호환성 참고 사항
  • 라이브러리
  • 안정화된 API
  • const로 안정화된 API
  • Rustdoc
  • 언어
  • 컴파일러
  • 플랫폼 지원
  • 내부 변경 사항
  • 기타

안정화된 API와 const로 안정화된 API는 모두 대략 다음과 같은 형식으로 작성해야 합니다.

- [`std::ptr::null_mut`](https://doc.rust-lang.org/std/ptr/fn.null_mut.html)
<!-- for trait implementations: -->
- [`impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T>`](https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E)

다음 사항에 유의하십시오.

  • 이것은 PR 링크가 아니라 표준 라이브러리 문서로 바로 연결되는 링크입니다.
  • 링크는 stable 문서를 가리키므로 작성 시점에는 실제로 동작하지 않을 수 있습니다.
  • API를 직접 적습니다. 문구가 너무 길어지지 않도록 API를 축약하기도 합니다(예: 부호 없는 정수를 uN으로 표기).
  • 링크 프래그먼트는 길고 예측하기 어려울 수 있으므로 직접 작성하기보다 URL을 복사해 붙여 넣는 편이 나을 때가 많습니다(항목이 stable 문서에 없다면 nightly 문서에서 복사한 뒤 URL을 수정하면 됩니다).
  • 트레이트 구현만 안정화되고 해당 트레이트는 안정화되지 않는 경우, 모든 impl을 나열하고 각 impl 블록으로 가는 링크를 붙입니다.

릴리스 팀: 3단계: 릴리스 노트가 필요한 모든 이슈/PR에 relnotes 레이블이 붙어 있는지 확인합니다

이 단계는 beta 기간의 처음 3주 이내에 진행해야 합니다(빠를수록 좋습니다). 이 작업은 더 넓은 Rust 프로젝트의 도움을 받아 진행할 수도 있습니다.

GitHub의 rust-lang/rust 풀 리퀘스트에서 is:pr milestone:1.85.0 is:merged -label:relnotes -label:relnotes-perf -label:finished-final-comment-period를 검색하고, 마일스톤은 상황에 맞게 바꾸십시오.

이렇게 하면 아직 상정되지 않은 병합된 PR을 모두 찾을 수 있습니다. 보통 수백 개가 나오며, 목표는 상정되었어야 했던 것으로 눈에 띄는 항목을 찾아 relnotes 레이블을 붙여 상정하는 것입니다. 항목을 하나하나 클릭해 들어가지 않고 목록을 스크롤하면서, GitHub 체크박스 UI로 이슈에 레이블을 일괄로 붙이는 것이 좋은 방법입니다.

여기서의 목표는 100% 빠짐없이 찾는 것이 아니라 주로 명백한 것을 잡아내는 것입니다. 일부를 놓치더라도 대체로 괜찮습니다. 일관된 패턴이 보인다면 triagebot의 자동 이슈 등록에 포함할 수 있도록 기록해 두십시오.

FIXME: 이 단계에는 relnotes 레이블이 붙은 채 닫힌 이슈에 마일스톤을 지정하려는 시도도 포함해야 할 수 있습니다. 현재 이러한 이슈에는 마일스톤이 지정되지 않으므로, 이에 대응하는 relnotes 추적 이슈는 아마 한 번도 포함되지 않을 것입니다(그래서 무기한 누락될 수 있습니다).

FIXME: 호환성 참고 사항(Compatibility Notes)에 대한 절차는 어떻게 합니까?

릴리스 팀: 4단계: 릴리스 노트 생성 시작

이 단계는 beta 기간의 처음 3주 이내에 진행해야 합니다(빠를수록 좋습니다). 현재 릴리스를 맡은 릴리스 팀 담당자가 relnotes 도구를 실행합니다.

cargo build
GITHUB_TOKEN=$(gh auth token) cargo run --bin relnotes -- 1.85.0 > relnotes.md

이 도구는 다음과 같은 콘솔 출력(stderr)을 생성합니다.

Did not use "Libraries" from Tracking issue for release notes of #132515: Fix and undeprecate home_dir() <https://github.com/rust-lang/rust/issues/132650>
Did not use "Category (e.g. Language, Compiler, Libraries, Compatibility notes, ...)" from Tracking issue for release notes of #132187: Add Extend impls for tuples of arity 1 through 12 <https://github.com/rust-lang/rust/issues/133975>

이러한 줄은 대개 누군가가 내용을 갱신하지 않았거나 위 목록에 없는 키워드를 사용했다는 뜻입니다. 예를 들면 다음과 같습니다.

  • Libraries는 Library여야 합니다
  • Category …를 갱신해야 합니다.

도구를 실행한 사람은 해당 이슈로 가서 올바른 내용으로 갱신해야 합니다(예: 이름 변경, 분류 지정). 기준이 되는 원본은 도구의 로컬 출력이 아니라 이슈입니다. 장기적으로는 도구 실행을 자동화하려 하므로 이 점이 중요합니다. 따라서 결과물인 relnotes.md를 로컬에서 수정하는 양을 최소화하도록 하십시오.

이 도구의 표준 출력은 위의 relnotes.md로 보내집니다. 현재 이 파일에는 각 섹션별로 서식이 적용된 헤더가 들어 있으며, 각 섹션에는 “Tracking issue for …” 추적 이슈에서 가져온 내용이 들어가거나, 또는 도구가 “tracking issue for …” 추적 이슈를 찾지 못한 경우에는 표준 내용(PR/이슈 제목 + 링크)이 들어갑니다.

이슈가 누락되었다면 3단계(이슈에 태그를 지정하고 도구를 다시 실행)를 참고하십시오. 이슈가 있어서는 안 되는데 포함되어 있다면, 해당 이슈에 relnotes 태그를 지정하고(또는 기존 relnotes 추적 이슈를 찾고) 그 추적 이슈를 닫는 것이 가장 좋습니다. 이렇게 하면 해당 항목이 도구의 출력에서도 빠집니다.

릴리스 팀: 5단계: relnotes PR 게시

1.84의 예시를 참고하십시오: https://github.com/rust-lang/rust/pull/134568

로컬에 있는 relnotes.md를 가져와(현재는 보통 라이브러리 안정화 항목이 빠진 상태이며, 이 항목은 나중에 추가합니다. 이 항목이 빠진 사본을 가능한 한 일찍 받아 두려는 것입니다) rust-lang/rust의 RELEASES.md 맨 위에 삽입하고, 그 내용으로 새 풀 리퀘스트를 여십시오. 이번 주기에 실제로 릴리스를 게시하는 담당자를 r?로 지정하고 릴리스 팀을 cc하면 됩니다.

PR 설명에 이 문서(https://forge.rust-lang.org/release/release-notes.html)의 링크를 포함하고 6단계를 가리키도록 하십시오(즉, 수정 사항은 PR이 아닌 곳에서 제안하도록 권장합니다).

다음 릴리스 팀 회의에서는 블로그 게시물 주제를 선정하기 위해 이 풀 리퀘스트도 논의해야 합니다(블로그 게시물 절차는 아래를 참고하십시오).

relnotes PR과 릴리스 블로그 게시물을 위해 relnotes-interest-group에 핑 보내기

기여자는 (예를 들어 소속 팀을 대표하여) relnotes PR과 릴리스 블로그 게시물 리뷰를 돕는 데 관심이 있을 수 있습니다. relnotes-interest-group 마커 팀에 자신을 추가하면 핑을 받도록 옵트인할 수 있습니다.

relnotes PR과 릴리스 블로그 게시물을 작성할 때는 다음을 통해 이 알림 그룹에 핑을 보내 주십시오.

@rustbot ping relnotes-interest-group

전체: 6단계: relnotes PR의 수정 사항 반영

보통 PR에는 오타 수정, 대체 문구 제안 등이 담긴 댓글이 많이(수십 개) 달립니다. 좋은 전략은 이슈/PR의 원래 이슈를 업데이트하는 것(또는 이슈를 새로 등록하고 업데이트하는 것)으로, 이는 기본적으로 4단계에서 이미 로컬로 수행한 반복 작업과 맞추는 것입니다. 상태가 이슈에 오래 남아 있을수록 그 이슈의 업데이트를 알아차리고 PR에 반영하기가 더 쉬워집니다(도구를 다시 실행하기만 하면 됩니다).

수정 사항을 이슈에 반영하면 적절한 사람(예: PR 작성자/리뷰어)이 논의되고 있는 내용을 알 수 있도록 하는 데 도움이 됩니다.

릴리스 팀: 7단계: 추적 이슈 닫기

적절한 시점에 릴리스 팀 담당자는 해당 PR이 최종본임을 선언하고 현재 마일스톤과 연관된 모든 relnotes 추적 이슈를 닫아야 합니다(검색 예시). 이 작업은 GitHub UI에서 하는 것이 가장 쉽습니다.

FIXME: 이상적으로는 이 이슈들이 모두 relnotes PR에서 링크되어 서로 오가기가 더 쉬워야 합니다.

블로그 게시물 절차

릴리스 노트 PR을 게시한 후, 릴리스 팀의 다음 회의에서 어떤 블로그 게시물 주제를 원하는지 논의합니다. 이 논의는 보통 꽤 비공식적이며 반드시 최종적인 것은 아닙니다. 목표는 더 많은 관점을 제공하여 블로그 게시물 작성자의 선택에 의견을 보태는 것입니다.

그런 다음 블로그 게시물 작성자는 가능한 한 빨리(보통 릴리스 3일에서 7일 전이지만, 더 짧은 기간에 처리한 적도 있습니다) 블로그 게시물 PR을 올리는 것을 목표로 하며, 이 PR은 리뷰와 수정을 거쳐 최종적으로 릴리스 당일에 병합됩니다.