Semantic Versioning 2.0.0 에 대한 자료 정리

Gradle이라던가 Maven을 이용한 빌드 시스템을 구축하고 NEXUS 등의 리포지터리를 이용하고 Git 을 쓰면서 개발을 하다 보면 예전에는 별로 관심이 없었던 개발하고 있는 시스템의 버전관리에 대한 생각을 하게 되더군요(최소한 저의 경우는 그랬습니다)
혹시라도 공통 라이브러리 패키지가 있을때는 공통 라이브러리에 대한 버전관리가 예전부터도 중요하게 생각되었었지만, 최근에는 이 공통 라이브러리 패키지를 이용하지 않는데도 버전관리가 예전보다 더 중요하게 생각이 됩니다.
다른 부분들은 그렇다 쳐도 Git을 이용해서 형상관리를 하는 경우에는 특정 커밋에 태깅을 해 놓는 것이 나중에 해당 버전의 상태를 추적하는데 매우 편리한 도구가 될 수 있습니다.

버전관리에서 최근 가장 많이 쓰는 방식이 Semantic Versioning 이라고 하는 것이 아닐까 생각합니다. 최근이라고 하지만 사실 예전부터 많이 사용됐었고 Semantic Versioning 이라는 개념을 몰라도 일반적으로 비슷하게 사용하는 x.y.z이라는 Major.Minor.Patch 방식의 버전관리입니다. 예를 들어 "릴리즈 최초버전은 1.0.0이다" 가 바로 Semantic Versioning(줄여서 semver 라고도 하더군요) 입니다.

다른 내용에 대해 검색을 하다가 우연히 해당 Semantic Versioning 에 대한 공식 문서를 찾았습니다.
semver 는 일반적으로 Public API에 대한 버전관리에 대해서 설명을 합니다만, 일반적인 프로그램에도 같게 적용될 수 있습니다.

결론적으로 가장 중요한 내용을 정리한다면,

• 기존 버전과 호환되지 않게 변경을 했다면 Major 버전
• 기존 버전에 새로운 기능이나 호환이 가능한 수정을 했다면 Minor 버전
• 기존 버전의 버그에 대해서 호환 가능하게 수정을 했다면 Patch 버전

(해당 버전) 부분을 하나씩 증가시킨다는 규칙을 말합니다.

일반 서비스를 개발하시는 분들의 경우는 조금 다를 수도 있겠네요. 저희도 제한적인 웹 서비스를 개발하고 있다 보니 일반적인 Public API와는 조금 다르게 적용이 됩니다.(서비스 초반에 잠깐 하다가 현재는 안 하고 있는 상황인데, 앞으로는 좀 잘해 보려 합니다.) Minor와 Patch는 같은 방식으로 버전관리가 가능하지만 Major의 경우에는 회사에서 정해지는 경우가 대부분이죠. "이번 프로젝트는 버전 2로 명명한다. 그리고 몇 달 또는 1년쯤 지난 후에 이번 개발부터 버전 3 로 명명할 거야." 라는 식으로 Major가 결정되는 경우가 많이 있습니다.

어찌 됐건 개인적으로 생각할 때는 Minor와 Patch 버전만 관리 한다 해도 Git에 태깅되어있는 버전번호를 보면 이 릴리즈가 버그 수정의 Patch 수준이었는지 신규 기능이 추가되었거나 대규모 수정의 수준이었는지에 대한 파악이 될 수 있으니 매우 유용합니다. 저희처럼 버전관리가 대충이거나 하지 않거나 다른 방식으로 하는 분들은 한 번쯤 내용을 보시고 도입을 검토해보시는 것도 나쁘지 않아 보이네요. (아마도 대부분 이 방식을 쓰고 있다고 생각이 되긴 하네요)

사실 저희 다음 프로젝트에 적용할 때 참고하고자 블로그에 올리면서 잠시 주절거려봤습니다.

제가 검색할 당시에 대략 18개 언어로 번역되어 서비스되고 있는듯하고 물론 한국어도 있습니다. (한국어 번역은 김대현님이 하셨네요. 감사합니다.)

한국어판 링크 : http://semver.org/lang/ko/