태그의 버전은 어떻게 명시하는가?

아래 자료를 참고하셔서 작업하시면 됩니다.

https://velog.io/@i33w/semver

https://semver.org/lang/ko/

공통 프로젝트

태그명은 기존의 snap shot 버전명을 따라갑니다. (기존 pom.xml 참고.)

공통 프로젝트는 태그 작업시
pom.xml
이 경로에 있는 버전 정보도 같이 수정 요청드립니다.

common project의 sementic versioning 관련 전략

• x.y.z
  • x : 프로젝트를 새로 작업하는 경우, 또는 대대적인 수정으로 api 모든 end point의 테스트 가 필요한경우.
  • y : 호환성이 깨지는 경우, 해당 변경사항이 개별 api에 영향을 주어, 개별 api의 변경이 필요한 경우
  • z : 호환성이 유지되는 경우, 버그 수정. 개별 api의 변경이 필요 없음.

api 프로젝트

태그를 x.y.z 형식으로 따면 됩니다.

최초 태그 x.y.z 버전은 1.0.0 입니다.

Sementic versioning 의견

rest api 의 sementic versioning 관련한 전략

• x.y.z
  • x : 프로젝트를 새로 작업하는 경우, 또는 대대적인 수정으로 api 모든 end point의 테스트 가 필요한경우.
  • y : 아래 1-3번 중 하나에 해당하는 경우
    • 1. api의 파라미터 path 수정시
    • 2. query parameter, request body, response body에서 특정한 키를 수정하거나 삭제 시.
    • 3. query parameter, request body, response body에서 필수적인 키를 추가시.
    • 4. javascript 코드의 변경이 필요함.
  • z : 아래 1,2,3번에 모두 해당하는 경우
    • 1. y에 해당하는 변경 사항이 없는 버그의 수정 건.
    • 2. query parameter, request body, response body에서 새로운 키를 옵션으로 추가할 경우.
    • 3. javascript코드의 변경이 필요 없는 경우.
• 위 전략으로 하게 될경우
  • api 호환성이 유지되는 경우 : patch 버전(z)변경시.
  • api 호환성이 깨지는 경우 : major, minor 버전 변경시.
• 보통 minor 버전의 변경 까지 호환성이 유지되어야 하지만, 저희의 버전 관리 방식에 맞지 않다고 생각되네요.
  • 이유 :
    • 저희 version닝 전략은 knot 전략으로 모든 API 사용자가 단 하나의 버전에 묶여 있음. api end point 마다 버전을 달리했다면, minor 버전(y)까지 호환성을 유지하는 것이 괜찮아 보임.
    • 하지만 지금은 모든 api(프로젝트 내의)가 하나에 묶임. 따라서 매 변경시마다 major 버전을 변경하면, major 변경사항이 많고, 대대적인 변경사항을 따로 구분지어 표현할 수 없는 이슈가 있습니다.

버전 관리 참고자료

https://velog.io/@eastperson/API-버저닝-전략#reference