Software 버전 관리 규칙, 너만 모르는 Semantic versioning
소프트웨어를 개발하다보면 정말 수많은 규칙들을 세우고 없애고 수정하는 것 같아요.
저도 혼자 개발하고 흡–족 할 때는 이런 규칙과 컨벤션들에 대해 무관심 했었는데,
이제 프로로 데뷔한지 2년 정도 지났고, 최근 이직한 회사에서 컨벤션 관련된 작업을 진행하면서 함께 정했던 버전 관리 규칙 에 대해 공유하려고 합니다.
사실 개발자들 뿐만 아니라 개발자가 아닌 일반인 분들에게도 이 버전명 에 대해서는 익숙한 분이 많을거라 생각해요.
79.0.3945.130
크롬의 최신 버전
어떤가요? 익숙한가요? 20년 2월 2일 기준 최근 크롬 공식 버전입니다.
크롬의 경우 뭔가 4자리로 구분 되어 있어서 어색할 수 도 있는데요.
우리가 흔히 접하는 모바일 어플리케이션을 살펴 볼까요?
목표 관리 앱, 챌린저스의 버전 기록
1.2.6
이번엔 어떠신가요? 많이 익숙한 숫자의 모습이죠?
다른 소프트웨어는 어떨까요?
모바일 게임 앵그리버드의 최신 버전
8.0.1
모바일 게임에서 꾸준히 상위 랭크에 올라가 있는 앵그리 버드의 앱스토어 최신 버전입니다.
여기에서도 익숙한 숫자의 형태가 보이는데요..?!
여러분들이 익숙한 저 형태의 버전은 Semantic versioning 이라는 규칙을 따른 버전 이름이에요.
제가 느끼기엔 대부분의 소프트웨어 버전 관리 규칙은 Semantic versioning 를 기반으로 만들어지는 것 같습니다.
그렇다면 Semantic versioning 은 어떤 규칙들이 있는 걸까요?
Semantic versioning
Github 창업하신 분이 기존 Versioning 의 문제점을 해결하고자 만든 제안이라는데..
사실 우리에게 그런 히스토리보단 직접 예를 보는게 더 좋겠죠?
(이런 히스토리는 따로 찾아보..읍읍)
Major.Minor.Patch
Semantic versioning 은 이렇게 생겼습니다.
간단하죠? 그리고 익숙한 저 모습..!
(그리고 위에서 봤던 크롬의 처럼 Patch 뒤에 Build 라는 자리수가 더 오는 경우도 있다고 하네요.)
그렇다면 Major, Minor, Patch 가 각각 어떨 때 숫자를 올려야 하고, 우리는 어떻게 사용하면 될까요?
일반적인 규칙
- 버전 번호는 Major, Minor, Patch 의 형태로 배포하고, Major, Minor, Patch 는 각각 자연수이고 절대 앞에 0이 붙어서는 안된다.
- 각 번호의 수는 항상 증가해야 한다.
- 특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
- Major 버전이 변경될 때, Minor, Patch 는 0으로 초기화 된다.
- Minor 버전이 변경될 때, Patch 는 0으로 초기화 된다.
Major 버전 증가
- 하위 버전과 호환되지 않는 변화가 생겼을 때
- 대대적인 변화가 일어났을 때
- 클라이언트가 1.0.0 버전의 API 접근 방식으로 2.0.0 버전에 접속할 수 없을 때
Minor 버전 증가
- 하위 버전과 호환이 되면서, 새로운 기능이 추가 될 때
- 새로운 기능이 추가된 API 가 나왔지만, 기존의 공개된 API 가 하위 호환되고 있을 때
- 기존의 기능이 변경되거나 사용 방법이 변경 되었을 때
Patch 버전 증가
- 버그 수정
- 기존 클라이언트가 알아차리지 못할 정도의 작은 변화가 있을 때
- 서버 코드 내부적으로 소스가 수정되었을 때
- 당연한 얘기겠지만, 이 모든 것들이 하위 버전과 호환될 때
이렇게 적어놓고 보니, 뭔가 어렵고 복잡한거 같지만 정리해보면
Major -> 다 바뀜
Minor -> 기능이 추가랑 조금 바뀜
Patch -> 버그 고쳤음
이렇게 정리할 수 있겠습니다.
정리하고 보니 정말 간단해 보이는군요..!!
그럼 이제 우리도 다른 오픈 소스들이..그리고 많은 제품들이 사용하는 Semantic Versioning 을 사용하는 겁니다!
추가적으로 Semantic Versioning 에는 위에서 언급하지 않은 다른 규칙들도 있습니다.
Semantic Versioning을 쓰는 소프트웨어는 반드시 공개 API를 정의해야 한다. 이 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어있어야 한다. 이 과정은 포괄적이며 정확해야 한다.
Major 버전 0 은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 이 공개 API 는 안정판으로 보지 않는 것이 좋다.
1.0.0 버전은 공개 API 를 정의한다. 이후의 버전 번호는 이때 공개 API 에서 어떻게 바뀌는지에 따라 올린다.
Patch 버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 정식 배포를 앞둔 (pre-release) 버전을 표기할 수 있다.
이런 규칙들도 있으니 참고해주세요!
그리고 Semantic Versioning 은 공식 홈페이지도 있습니다.
그것도 무려… 27개국의 언어를 지원하는..!!
그 중에 한국어도 있으니 홈페이지 가셔서 살펴보셔도 좋을거 같네요.
제 포스팅이 도움이 되었으면 좋겠네요.
다른 질문이 있으신 분은 아래 댓글 적어주세요! 꼭 답변 드리도록 하겠습니다.
긴 글 읽어주셔서 감사합니다!
참고 페이지
(새창으로 이동합니다.)
Versioning버전 관리 규칙Semantic versioningVersion naming rules
2020-02-02 01:30 +0900