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“라는 제목으로 새 이슈가 자동으로 생성됩니다. 이는 해당 릴리스 노트를 위한 추적 이슈입니다. 이 이슈에는 relnotes + relnotes-tracking-issue 라벨이 붙습니다.

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

이상적으로는 코드 블록에 텍스트를 직접 편집해 넣지만, 권한이 없는 경우 스레드에서 논의가 이루어질 수 있으며 이후 릴리스 팀이 이를 반영합니다.

릴리스 노트 텍스트는 이후 단계에서 자동으로 가져오며, 가능하면 this list의 헤더를 사용해야 합니다:

  • 호환성 참고 사항
  • 라이브러리
  • 안정화된 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)

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

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

릴리스 팀: 3단계: 릴리스 노트가 필요한 모든 이슈/풀 리퀘스트에 relnotes 레이블이 붙었는지 확인

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

rust-lang/rust 풀 리퀘스트에 대해 GitHub에서 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 풀 리퀘스트 게시

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 풀 리퀘스트와 릴리스 블로그 게시물을 작성할 때는 다음을 통해 이 알림 그룹에 핑을 보내 주십시오

@rustbot ping relnotes-interest-group

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

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

이슈에 편집 내용을 추가하면 적절한 사람들(예: 풀 리퀘스트 작성자/리뷰어)이 논의 중인 내용을 파악하는 데 도움이 됩니다.

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

어느 시점에서, 릴리스 팀 담당자는 해당 풀 리퀘스트를 공식으로 선언하고 현재 마일스톤과 연관된 모든 relnotes 추적 이슈를 닫아야 합니다(검색 예시). GitHub UI에서 이를 수행하는 것이 가장 쉽습니다. 이 작업은 GitHub UI에서 하는 것이 가장 쉽습니다.

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

블로그 포스트 절차

릴리스 노트 풀 리퀘스트를 게시한 후, 릴리스 팀의 다음 회의에서는 원하는 블로그 게시물 주제를 논의합니다. 일반적으로 이는 상당히 비공식적인 논의이며 반드시 최종 결정은 아닙니다. 그 목적은 더 많은 관점을 제공함으로써 블로그 포스트 작성자의 선택에 참고할 의견을 제공하는 것입니다.

그런 다음 블로그 포스트 작성자는 가능한 한 빨리 블로그 포스트 PR을 게시하는 것을 목표로 하며(일반적으로 릴리스로부터 3~7일 전이지만 더 짧게 진행된 경우도 있었습니다), 이후 검토와 편집을 거쳐 마침내 릴리스 당일에 병합됩니다.