이 문서는 Bazel 참여자를 대상으로 합니다.
Bazel의 커밋 설명에는 RELNOTES: 태그 다음에 출시 노트가 포함되어 있습니다. Bazel팀이 각 출시의 변경사항을 추적하고 출시 알림을 작성하는 데 사용됩니다.
개요
변경사항으로 인해 버그가 수정되었나요? 이 경우 출시 노트가 필요하지 않습니다. GitHub 문제에 관한 참조를 포함하세요.
변경사항으로 인해 사용자에게 표시되는 방식으로 Bazel이 추가 / 삭제 / 변경된다면 이를 언급하는 것이 유리할 수 있습니다.
변경사항이 중대하다면 먼저 디자인 문서 정책을 따르세요.
가이드라인
출시 노트는 사용자가 읽을 수 있으므로 간결하게 (한 문장이 이상적임) 전문 용어 (Bazel 내부 용어)를 피하고 변경사항의 내용에 초점을 맞춰야 합니다.
관련 문서 링크를 포함합니다. 거의 모든 출시 노트에는 링크가 포함되어 있습니다. 설명에 플래그, 기능, 명령어 이름이 언급되어 있는 경우 사용자는 이에 대해 더 알고 싶어 할 수 있습니다.
코드, 기호, 플래그 또는 밑줄이 포함된 모든 단어를 역따옴표로 묶습니다.
버그 설명을 단순히 복사하여 붙여넣지 마세요. 이런 단어는 종종 수수께끼로 다가서서 우리에게만 의미가 있으며 사용자가 머리만 긁게 만듭니다. 출시 노트는 사용자가 이해할 수 있는 언어로 변경된 내용과 이유를 설명하기 위한 것입니다.
항상 현재 시제를 사용하고 'Bazel이 이제 Y를 지원합니다' 또는 'X가 이제 Z를 지원합니다' 형식을 사용합니다. Google에서는 출시 노트가 버그 항목처럼 들리는 것을 원하지 않습니다. 모든 출시 노트 항목은 정보를 제공해야 하며 일관된 스타일과 언어를 사용해야 합니다.
지원 중단되었거나 삭제된 항목이 있는 경우 'X가 지원 중단되었습니다.' 또는 'X가 삭제되었습니다.'를 사용합니다. '삭제됨' 또는 '삭제됨'이 아님
Bazel이 이제 다른 동작을 한다면 현재형으로 '$oldBehavior 대신 $newBehavior'X를 사용합니다. 이를 통해 사용자는 새 버전을 사용할 때 예상되는 사항을 자세히 알 수 있습니다.
이제 Bazel이 무언가를 지원하거나 더 이상 지원하지 않는 경우 'Bazel이 이제 X를 지원하거나 더 이상 지원하지 않음'을 사용합니다.
삭제 / 지원 중단 / 변경된 이유를 설명하세요. 한 문장으로도 충분하지만 사용자가 빌드에 미치는 영향을 평가할 수 있어야 합니다.
향후 기능에 대해 약속하면 안 됩니다. '이 플래그가 삭제됩니다' 또는 '변경됨'은 피해야 합니다. 이로 인해 불확실성이 발생합니다. 사용자가 가장 먼저 궁금해하는 것은 '언제?'입니다. Google에서는 사용자가 현재 빌드가 알려지지 않은 시간에 손상될까 봐 걱정하는 것을 원하지 않습니다.
프로세스
출시 프로세스의 일환으로 모든 커밋의 RELNOTES 태그를 수집합니다. 메모를 검토, 수정, 정리하는 Google 문서에 모든 항목이 복사됩니다.
출시 관리자가 bazel-dev 메일링 리스트에 이메일을 보냅니다. Bazel 참여자는 문서에 기여하고 변경사항이 공지사항에 올바르게 반영되었는지 확인합니다.
나중에 공지는 bazel-blog 저장소를 사용하여 Bazel 블로그에 제출됩니다.