콘텐츠로 이동

릴리스 노트에 변경 사항 정보 추가

많은 BeeWare 도구는 각 릴리스의 릴리스 노트를 작성하는 데 towncrier를 사용합니다. 해당 도구 중 하나에 풀 리퀘스트를 제출할 때는 변경 사항 설명을 포함해야 합니다. 이 변경 사항 설명은 릴리스 노트에 포함되어 수행된 변경 사항을 설명하는 항목이 됩니다.

모든 풀 리퀘스트에는 changes/ 디렉터리에 최소 한 개의 파일이 포함되어야 하며, 해당 파일은 풀 리퀘스트로 구현된 변경 사항에 대한 간략한 설명을 제공해야 합니다. 변경 노트는 마크다운 형식으로 작성되어야 하며, 파일 이름은 <id>.<fragment type>.md 형식을 따라야 합니다. 제안하는 변경 사항이 기존 이슈 번호가 있는 버그 수정 또는 기능 구현인 경우, 해당 티켓 번호를 ID로 사용합니다. 해당 변경 사항에 대응하는 이슈가 없는 경우, PR 번호를 ID로 사용할 수 있습니다. 이 PR 번호는 풀 리퀘스트를 푸시하기 전까지는 알 수 없으므로, 첫 번째 CI 통과 시 towncrier 검사가 실패할 것입니다. 변경 사항 설명을 추가하고 PR 업데이트를 푸시하면 CI가 통과될 것입니다.

다섯 가지 조각 유형이 있습니다:

  • feature: 이 PR은 이전에는 불가능했던 새로운 동작이나 기능을 추가합니다(예: 새로운 패키징 형식 지원 추가, 기존 패키징 형식의 새 기능 추가);
  • bugfix: 이 PR은 기존 구현체의 버그를 수정합니다;
  • PR은 문서화에 상당한 개선을 가져왔습니다;
  • removal; 이 PR은 BeeWare API에서 하위 호환성이 없는 변경 사항을 나타냅니다; 또는
  • misc; 릴리스 노트에 공지할 필요가 없는 사소한 변경 또는 관리적 변경(예: 오타 수정, 사소한 언어적 명확화, 종속성 버전 업데이트 등).

변경 노트의 이 설명은 사용자의 관점에서 변경 사항에 대한 고수준의 "마케팅" 요약이어야 하며, 심층적인 기술적 설명이나 구현 세부사항이 아닙니다. 이는 커밋 메시지와 구별됩니다. 커밋 메시지는 향후 개발자가 변경 사유를 추적할 수 있도록 수행된 작업을 설명하는 반면, 변경 노트는 내부 구조에 대한 지식이 없을 수 있는 사용자를 위한 설명입니다.

예를 들어, 프로젝트 이름 지정과 관련된 버그를 수정했다면 커밋 메시지는 다음과 같을 수 있습니다:

숫자로 시작하는 프로젝트 이름을 허용하지 않도록 더 강력한 정규 표현식 검사를 적용하십시오.

해당 변경 노트는 다음과 같이 작성될 것입니다:

프로젝트 이름은 더 이상 숫자로 시작할 수 없습니다.

일부 PR은 여러 기능을 도입하고 여러 버그를 수정하거나, 여러 하위 호환성 없는 변경 사항을 도입할 수 있습니다. 이 경우 PR에는 여러 개의 변경 사항 설명 파일이 있을 수 있습니다. 동일한 ID로 두 개의 조각 유형을 연결해야 하는 경우 숫자 접미사를 추가할 수 있습니다. 예를 들어, PR 789가 티켓 123에 설명된 기능을 추가하고 티켓 234에 설명된 버그를 해결하며 두 가지 하위 호환성 없는 변경 사항을 수행한 경우, 다음과 같이 총 4개의 변경 사항 설명 파일이 있을 수 있습니다:

  • 123.feature.md
  • 234.bugfix.md
  • 789.removal.1.md
  • 789.removal.2.md

towncrier 및 조각 유형에 대한 자세한 내용은 뉴스 조각을 참조하십시오. 또한 changes 저장소의 BeeWare 디렉터리에서 기존 뉴스 조각 예시를 확인할 수 있습니다. 이 폴더가 비어 있다면, BeeWare가 최근 새 릴리스를 발표한 탓일 가능성이 높습니다. 변경 사항 노트 파일은 삭제되고 통합되어 각 릴리스마다 릴리스 노트를 업데이트합니다. 필요한 주석 스타일을 확인하려면 해당 파일을 참조하십시오. 변경 사항 노트 서식 방법은 최근 병합된 PR을 참고하십시오.