밤 늦게까지 여는 카페

시맨틱 버저닝 pre-release & build metadata - "-", "+"에 의미가 있는 줄은 몰랐네요 ㄷㄷ 본문

DevOps

시맨틱 버저닝 pre-release & build metadata - "-", "+"에 의미가 있는 줄은 몰랐네요 ㄷㄷ

Jㅐ둥이 2023. 8. 13. 23:08
반응형

안녕하세요. 오늘은 Semantic Versioning(시맨틱 버저닝)의 pre-release와 build metadata에 대해서 공부해보려고 합니다.
 

1. Semantic Versioning 이란

많은 분들이 알고 계시겠지만 시맨틱 버저닝은 대표적인 버저닝 규칙으로 "x.y.z" 형태로 버전을 표시합니다. x가 major 버전, y가 minor 버전, z가 patch 버전입니다.
 
각각의 버전들을 증가시키는 경우는 다음과 같습니다.

  • patch 버전은 하위호환성을 지키면서 버그가 수정되었을 때 증가시킵니다.
  • minor 버전은 하위호환성을 지키면서 기능이 추가되었을 때 증가시킵니다.
  • major 버전은 하위호환성이 지켜지지 않는 기능이 추가될 때 증가시킵니다.

 
하위호환성이라고 어려운 말을 사용했지만 버전이 바뀌었을 때 API를 사용하는 클라이언트가 무엇인가 조치를 취해야 하는가? 를 짧게 쓴 용어입니다.

  • 버전이 바뀌었을 때 클라이언트가 코드를 변경하거나 무언가 작업을 해야한다면 하위호환성이 지켜지지 않는 것이죠.

딱, 여기까지의 내용까지만 알고 시맨틱 버저닝을 사용했습니다.
그래서 뒤에 아무렇게나 내용을 붙였는데요.
 
예를 들어서, 현재 운영 서버에 배포된 버전이 1.5.20입니다
운영 중에 버그가 발견되어서 핫픽스를 진행하기로 결정하고, 해당 버전은 1.5.20-hotfix1 과 같은 방식으로 정했습니다.
뒤의 내용은 크게 중요하지 않고 alphanumeric 순서로 정렬되기만 하면 된다 식으로 생각했던 것인데요.
 
별다른 생각 없이 버전을 찍고 있었는데 동료분이 "x.y.z-{pre-release}", "x.y.z+{build-metadata}"에 관해서 지적을 해줬습니다.
 

2. pre-release와 build metadata

2.1. pre-release

정확히 알아보니 "x.y.z-{pre-release}"와 같은 형태는 pre-release에 대한 버전을 만들 때 사용하는 방식이더라고요.
pre-release라는 이름에 담긴 의미처럼 버전 "x.y.z-{pre-release}"는 버전 "x.y.z"보다 이전 버전이라는 뜻을 가지고 있습니다.

  • 누군가 두 개의 버전 "1.5.20-hotfix1", "1.5.20"을 주고 어떤 것이 더 최신 버전이냐고 묻는다면 시맨틱 버저닝 규칙을 따른다면 "1.5.20"이 최신버전이라고 답할 수 있는 것입니다.

2.2. build metadata

"x.y.z+{build-metadata}"와 같은 형태는 build metadata를 버전에 표현할 때 사용하는 방식입니다.
build metadata는 메타데이터이므로 이미 완성된 버전에 사이드 메뉴를 추가한 것이라고 생각하면 됩니다.
 
그렇다면 버전 "1.5.20+feature1"과 "1.5.20" 중에서 어떤 버전이 최신 버전일까요?
1.5.20+feature1이라고 생각하실 수 있지만 시맨턱 버저닝에서는 둘 간의 우선 순위는 동일합니다.
사이드 메뉴가 추가된 것 뿐이기 때문에 두 버전 자체는 똑같다고 생각하시면 될 것 같습니다.
 
만약에 pre-release 버전에 build metadata 내용을 넣고 싶다면 어떻게 작성해야 할까요?
시맨틱 버저닝에서는 pre-release 버전을 먼저 작성하라고 명시되어 있습니다. 1.5.20-hotfix1+feature1 같은 방식입니다.
 

3. 그래서 시맨틱 버저닝 어떻게 쓰는건데?

무엇이 정답인지, 올바른 것인지 따지는 것보다는 지금까지 제가 사용했던 방식을 조금 더 개선하는 방향을 찾아보겠습니다.

 

저는 지금까지 긴급한 버그 수정 작업들이 적용된 버전을 "-hotfix"를 붙였는데요. 이렇게 하는 대신 patch 버전을 증가시키는 것이 더 좋은 방법입니다. 그런데 저는 patch 버전을 증가시키지 않았던 이유가 있습니다.

 

이미 patch 버전을 증가시켰는데 이전 버전에서 버그가 발생하면 버전을 관리하는 것이 까다로워지기 때문입니다. 바로 버전 관리에 분기점이 생기게 되는 것이죠.

 

버전 관리에 분기점이 생성되는 것을 예방하기 위해서는 복합적인 관리가 필요하겠더라고요.

운영 서버에 배포할 때는 minor 버전이 꼭 바뀌어야 하는데 이를 위해서는 기능에 따른 minor 버전 관리가 엄격히 이뤄져야 합니다. 당연히 버그 관리도 잘 이뤄져야겠지요...


시맨틱 버저닝에 대해서 새롭게 알게 된 내용을 정리해봤습니다. 시맨틱 버저닝에 대한 원문은 https://semver.org 에서 확인하실 수 있으니 더 궁금하신 내용은 원문에서 찾아보실 수 있을거에요!
 
P.S.
함께 일하는 동료가 누군지는 정말 중요한 것 같습니다. 배움과 성장의 기회를 만들어주니깐요!

반응형