버저닝 정책에 대한 생각

TIP

구 블로그에 남겨둔 기록을 옮겨왔다.

Software versioning | Wikipedia (opens new window)

유의적 버전 2.0.0-ko2 | semver.org (opens new window)

프로젝트 하면서 버젼 매길때마다 항상 애매하게 매기고 혼란이 오고 반복이 된다. 찾아보니 표준까진 아니지만 사실상 표준처럼 쓰이는 semver라는 정책이 있더라. 한글버젼도 있으니 참고.

그런데 semver라고 해서 무조건 장점만 있는것은 아니고 애매하거나 단점도 존재한다. 대표적으로 FAQ에도 나와있는, 주버젼이 너무 빨리 증가한다는 특징이다. nodejs도 벌서 78버전, react는 15버전이 안정버젼이다. Angular2는 더 이상하게 2버전부터 semver를 사용하기 시작하면서 router 모듈만 먼저 3버전으로 올라가는 바람에 지난주에 새버젼은 4.x로 명명되었다.

물론 핫한 기술들이기 때문에 그럴수밖에 없다는 점도 이해는 되나, 6개월마다 주버젼이 올라가버리면 아무리 실제 호환성은 거의 유지된다 하더라도 인간이 느끼는 그 부담감은 생각보다 큰듯 하다. 잠깐 놓고 있다가 살펴보면 버전이 막 2.x에서 4.x로 뛰어있고 이런식이니...

내가 생각하기에는 semver에서 호환성이 깨지면 무조건 주버전을 올리는 정책이 있는데 이것이 양날의 검이다. 물론 개발자들이 호환성 이슈를 판단하기에는 편할수도 있으나, 아주 사소한 스펙 변경이 실수로 들어가더라도 주버젼이 올라가버려야하는 것은 기계적 관점에선 당연한 정책일지 몰라도 인간이 느끼기에는 굉장히 불합리해보일 수도 있다. 예를들어 정말 1글자 스펙버그로 잘못 릴리즈되었으면, 1.0.0에서 1.0.1 이런식으로 가는게 오히려 낫지 2.0.0으로 가는건 너무 비효율적이라는 생각이 든다. 물론 1.0.0을 가지고 작업하던 개발자들에겐 혼란이 올수도 있겠으나 차라리 버그가 있는 버전이라고 사과하고 어떻게 수정해야하는지 특정버전에 코멘트를 다는게 더 낫다는 생각이다. 안그러면 이러다가 nodejs 100버젼 이런것도 곧 볼지도 모르겠다. 설마 그러진 않겠지?

아니면 1자리를 더 추가하여 1.0.0.0으로 하는건 어떨까. 아래 3자리는 semver정책이고 제일 상위 버전은 그냥 인간의 마음으로 주어지는 버젼말이다. 예를들어 Angular같은 경우 1.1.x.y이었다가 Angular2가 출시되었을 때 1.2.x.y로 가기엔 너무 달라졌기 때문에 이런 경우는 인간의 판단으로 2.0.x.y로 가는것이다. 그랬으면 지금처럼 Angular3, 4 버전 논란 대신 2.1.x.y -> 2.2.x.y가 되었을 것이다. 그랬으면 nodejs도 io.js와 통합시에 4버젼이 되는게 아니라 2.0.x.y가 되었을 것이고, 최신 버전이 7이 아니라 2.3.x.y가 되었겠지. 정말 아주 리메이크 수준이거나 새로 리포지토리를 따는 경우에만 첫자리를 올리면 훨씬 매끄러운 모습으로 보일것 같다는 생각을 해본다.

개인 프로젝트는 그렇게 해볼까 한다. 개인프로젝트는 하위호환성 깨지는게 예삿일이기 때문에, semver를 쓴다면 주버젼이 아마 순식간에 100버전이 넘어갈지도 모른다. ㅋㅋ