이 문서는 프로젝트에서 버전 태그를 관리하기 위한 규칙을 설명합니다. 우리 팀은 Semantic Versioning을 기반으로 v<주버전>.<부버전>.<수정 버전> 형식을 사용하여 버전을 관리합니다.

태그는 다음과 같은 형식을 따릅니다:

v<주버전>.<부버전>.<수정 버전>

• 예: v1.0.0, v2.1.3, v1.2.0.

• 주버전 (Major): 기존 기능과 호환되지 않는 큰 변경이 있을 때 증가합니다.

  • 예: 핵심 기능 변경, API 호환 불가 등.
  • 예시: v1.0.0 → v2.0.0.

• 부버전 (Minor): 하위 호환성을 유지하면서 새로운 기능을 추가할 때 증가합니다.

  • 예: 새로운 기능 추가, 성능 개선 등.
  • 예시: v1.0.0 → v1.1.0.

• 수정 버전 (Patch): 버그 수정이나 사소한 변경이 있을 때 증가합니다. 이 변경은 하위 호환성을 유지해야 합니다.

  • 예: 버그 수정, 문서 변경, 작은 성능 개선 등.
  • 예시: v1.0.0 → v1.0.1.

• 새로운 버전을 릴리스할 때 태그를 추가합니다:

  git tag v<주버전>.<부버전>.<수정 버전>

• 예:

  git tag v1.1.0

• 로컬에서 태그를 추가한 후, 이를 원격 저장소에 푸시합니다:

  git push origin v<주버전>.<부버전>.<수정 버전>

• 모든 로컬 태그를 원격에 한 번에 푸시하려면:

  git push origin --tags

• 로컬에서 태그를 삭제하려면:

  git tag -d v<주버전>.<부버전>.<수정 버전>

• 원격 저장소에서 태그를 삭제하려면:

  git push origin --delete v<주버전>.<부버전>.<수정 버전>

• 일관성 유지: 모든 태그는 반드시 v<주버전>.<부버전>.<수정 버전> 형식을 따라야 합니다.
• 의미 있는 변경: 각 버전 번호는 코드 변경의 성격에 맞게 선택되어야 합니다.
• 문서화: 새 버전이 릴리스될 때, 변경 사항을 정리하여 'Wiki/패치 노트'에 기록합니다.
• master 브랜치: 모든 태그는 master 브랜치에만 작성합니다.

• v1.0.0: 첫 번째 정식 릴리스.
• v1.1.0: 새로운 기능 추가.
• v1.1.1: 버그 수정 및 작은 변경 사항.
• v2.0.0: 기존 기능과 호환되지 않는 큰 변경이 포함된 업데이트.