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