출시 노트 작성

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

이 문서는 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 사용 저장소를 사용합니다.