티스토리 뷰
회사에 와서 다양한 프로젝트를 해봤다. 서버, 클라이언트, 안드로이드, iOS, Hybrid 앱까지 생각해보니 이것저것 찔끔찔끔 건드려는 보았던 것 같다. 지금 부서에 와서는 또 다른 일을 한다. 주로 라이브러리 개발이다.
아직 주니어 개발자인데 인력부족으로 1인개발 또는 개발리딩을 하려니 어려운 점이 부지기수다. 구현도 잘하려는 욕심은 끝이 없지만, 설계 단계에서 가장 머리를 싸매는게 '하위호환성', '버전관리'이다. 이 라이브러리는 내가 창시자가 아니라서 내가 물려받았을(?) 때 이미 1.0.5 버전이었다. 1.0.0 버전부터 개발을 해오던 개발자분은 이미 떠나셨고 나는 1.0.0에서 1.0.5 사이의 역사도 모른 채 이 라이브러리와 함께 대장정을 시작하게 되었다. 그러면서 지금은 2.1.x 버전이 되었다. 물론 버전 올리는건 내맘대로 였다!
기존에 남아있던 가이드 문서에서 나를 옭아매는건 아래의 문장...
모든 하위 버전을 호환해야 한다.
괜히 이렇게 적혀있으니 버전 올리는게 두렵고, 어쩔 수 없이 올려야 될 때면 이놈의 '하위호환' 때문에 API 설계에서부터 꽤 긴 시간을 보내왔던 것 같다. 그리고 버전을 올리는 기준이 명확하지가 않으니, 뭔가 아주 조금 고친 것 같으면 세번째 숫자를 고치고(2.0.0→2.0.1), 그래도 좀 눈에 띄게 고쳤다 싶으면 중간 숫자를 올리고(2.0.1→2.1.0), 대격변이다 싶을 때 첫번째 숫자를 올리면서(1.x.x→2.0.0) 지금까지 근근히 버텨왔다. 형상에서 tag도 따고 하는데 가끔가다가 소스 달랑 한줄 고쳐야 할 일이 있을 때는 슬쩍 버전 유지도 해가면서...
좋은 버전관리란 어떻게 하는걸까... 라고 생각만 하고 딱히 알아보지는 않는 와중에 회사 선배가 좋은 링크를 공유해주셨다.
친절하게도 처음부터 Summary가 있다. 그리고 "dependency hell"이라는 구문이 매우 와닿는 부분이었다.(ㅠㅠ) 원문을 기준으로 작성하지만 감사하게도 한글 번역을 해놓으신 분도 있다. 아래는 내 맘대로 중요한 내용과 내가 기억하고 싶은 내용을 정리해놓은 것.
[기본규약] X.Y.Z 형식으로 표기 (X, Y, Z는 자연수)
- X = Major version : public API가 호환되지 않는 변화가 생기는 경우 ↑
- Y = Minor version : 하위 호환성을 유지하며 새로운 기능이 추가되는 경우 ↑
- deprecated API가 생기더라도 Y를 증가시킨다.
- 내부 비공개 코드에 기능이 추가되거나 개선되어도 올린다. - Z = Patch version : 하위 호환성을 유지하며 bug fix를 하는 경우 ↑
[Additional label]
- 공통적으로 'dot separated identifiers[0-9A-Za-z-]'를 사용.
- pre-release version : '-'로 연결
ex. 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92 - build metadata 표기 : '+'로 연결
ex. 1.0.0-alpha+001, 1.0.0+20130313144700
[주의사항]
- 특정 버전으로 배포 후에는 변경하면 안 됨! 변경사항 반영 시에 항상 새 버전을 사용
- 우선순위 계산
1. X, Y, Z 차례로 각각 비교
2. X.Y.Z가 같을 경우 pre-release 버전이 표기된 것이 우선순위가 낮다
3. X.Y.Z가 같은 pre-release 버전 간의 비교
3-1. 숫자로만 구성된 경우 수의 크기로 비교
3-2. 알파벳이나 hyphen이 포함된 경우 아스키 문자열 정렬
3-3. 3-1은 항상 3-2보다 낮은 우선순위
3-4. 앞 부분이 모두 같으면 필드 수가 더 많은 쪽이 높은 우선순위
ex. 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
X.Y.Z 형식으로 세 자리인 것은 동일한데 버전 정책은 비슷하게 쓰던 것도 있고, 아예 이상하게 쓰던 것도 있다. 물론 이 Semantic Versioning이라는 것이 '꼭' 지켜야 하는 규칙은 아니지만, 누군가 이렇게 공들여서 정책의 기준을 제시해주었고(심지어 이 SemVer도 Versioning이 되고 있다!), 많은 사람들이 이에 동의하고 사용하고 있다는 점에서 충분히 적용해야 할 가치가 있어 보인다. 지금까지 해온 것들은 어쩔 수 없다고 치더라도, 앞으로의 버전 관리에는 신경써서 반영을 하려고 한다. 계속 언급한 라이브러리 외에 새로운 라이브러리를 맡게 되더라도 말이다.
출처)