이 문서는 Bazel 참여자를 대상으로 합니다.
Bazel의 커밋 설명에는 RELNOTES: 태그와 출시 버전이 포함됩니다.
참고 Bazel팀에서 각 출시의 변경사항을 추적하고
출시 발표
개요
변경사항이 버그 수정인가요? 이 경우 출시 노트가 필요하지 않습니다. 제발 GitHub 문제에 대한 참조를 포함하세요.
변경사항이 사용자에게 표시되는 방식으로 Bazel을 추가 / 삭제 / 변경하는 경우 언급하는 것이 유리할 수 있습니다.
중대한 변경이라면 설계 문서를 따르세요. 정책을 먼저 읽어보세요.
가이드라인
출시 노트는 사용자가 읽을 것이므로 짧아야 합니다. 전문 용어 (Bazel 내부 용어)를 피하고 중요한 역할을 합니다
관련 문서 링크를 포함하세요. 거의 모든 출시 노트는 링크를 포함할 수 있습니다. 설명에 플래그, 기능, 명령 이름이 언급된 경우 사용자는 아마도 그것에 대해 더 알고 싶어할 것입니다.
코드, 기호, 플래그 또는 밑줄로 표시됩니다.
버그 설명을 단순히 복사하여 붙여넣지 마세요. 대개 비밀스러우며 사용자가 머릿속을 긁지 않도록 하는 것입니다. 출시 노트는 변경된 내용과 그 이유를 사용자가 이해할 수 있는 언어로 설명합니다.
항상 현재 시제와 'Bazel이 Y를 지원합니다' 형식을 사용하세요. 또는 'X는 이제 Z." 출시 노트가 버그 항목처럼 들리지 않기를 바랍니다. 모든 버전 입력 내용은 유익해야 하며 일관된 스타일과 언어를 사용해야 합니다.
지원 중단되었거나 삭제된 항목이 있는 경우 'X는 지원 중단됨'을 사용합니다. 또는 'X' 이(가) 삭제되었습니다." '삭제됨' 아님 '삭제되었습니다.'라고 표시됩니다.
이제 Bazel이 다르게 하는 경우 'X 이제 $newBehavior'를 $oldBehavior" 있습니다. 이를 통해 사용자는 무엇을 해야 할지 자세히 알 수 있고 기대하는 내용입니다.
현재 Bazel에서 무언가를 지원하거나 더 이상 지원하지 않는 경우 'Bazel에서 이제 / 더 이상 X를 지원하지 않습니다.'
특정 항목이 삭제 / 지원 중단 / 변경된 이유를 설명하세요. 한 문장은 하지만 우리는 사용자가 빌드에 미치는 영향을 평가할 수 있기를 바랍니다.
향후 기능에 대해 약속하면 안 됩니다. "이 플래그는 삭제됨" 또는 "변경될 것입니다." 불확실성을 야기합니다. 가장 먼저 할 일은 사용자는 '언제?'가 궁금할 것입니다. 아이들이 데이터 애널리스트로서 일하게 될 현재 빌드가 알 수 없는 시간에 손상될 수 있습니다.
절차
이번 출시의 일환으로
,
모든 커밋의 RELNOTES 태그를 수집합니다. 우리는 모든 것을 Google
문서
여기에서 메모를 검토, 수정 및 정리할 수 있습니다.
출시 관리자가 bazel-dev 메일링 리스트에 포함되어 있습니다. Bazel 참여자는 문서에 참여하도록 초대되며 변경사항이 공지사항에 올바르게 반영되었는지 확인합니다.
나중에 공지가 Bazel에 제출됩니다. 블로그, bazel-blog 사용 저장소를 사용합니다.