Semantic Versioning

🏅 Goal

• Versioning 에 대해서 이해한다.
• Semantic versioning 에 대해서 이해한다.

🌱 Versioning부터 알아보자

소프트웨어 개발 생태계는 수많은 사람들이 서로의 기술과 성과를 이어받아 온다. 이를 통해 다른 사람들이 만들어온 기능을 다시 만들 필요 없이 손쉽게 가져와서 재활용하는 방식으로 빠르게 소프트웨어를 만들 수 있다.

하지만 여러 사람에게 이용되는 패키지가 새롭게 업데이트될 때, 생각보다 다양한 문제에 직면하게 된다. 기능의 사용법을 바꾸어버리거나 동작 방식의 변경 같은 변화들은 그에 의존하는 다른 소프트웨어를 의도대로 동작하지 못하게 하므로, 새로운 변화와 기존의 것을 구분할 필요가 생겼다.

버전이라는 개념은 이러한 패키지의 변화를 구분하기 위해 사용하기 시작했다.

🌱 Semantic versioning이 무엇이더냐

시맨틱 버저닝(Semantic Versioning)은 소프트웨어의 버전 변경 규칙에 대한 제안이다.

버전이라는 코드 형태의 구분방식은 많은 핵심 문제를 해결해주었지만, 아직 여러 과제가 남아있었다.

버전 명의 작성 방식에 관한 기준이 패키지마다 제각각 다른 것이 거참 통일성 없어보이네!

0.x와 1.x의 차이, 1.0.0 혹은 1.000. 선행 배포와 정식 버전의 구분 방법 등 모든 소프트웨어, 패키지는 저마다의 기준을 가지고 있었으며, 이는 어느 정도의 적당한 공통점이 있었지만, 그 점이 미묘하게 모두 차이가 있어 버전에 따른 의미 해석을 어렵게 했다.

Semantic Versioning은 Github의 공동창업자인 Tom Preston-Werner가 위의 문제를 해결하기 위해 기존의 현안을 모아 만든 제안이다. 스펙 문서는 RFC 2119에 의해 규칙을 표기하여 의미적 엄격함을 높이고, 패키지 개발 생명주기에 발생할 수 있는 여러 상황을 포괄적으로 담아 일관성과 유연성을 균형있게 갖추고 있다.

이러한 시맨틱 버저닝을 따르는 다양한 라이브러리들이 있다.

node.js: https://github.com/isaacs/node-semver
PHP: https://github.com/GordonSchmidt/SemVer
Python: https://github.com/k-bx/python-semver
Ruby: https://github.com/iantruslove/SemverStringer

🌱 특징

• Semantic Versioning을 쓰는 소프트웨어는 반드시 공개 API를 정의해야 한다. 이 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어있어야 한다.

• 일반 버전 명은 반드시 X.Y.Z 형태를 보여야 하며 X, Y, Z는 음이 아닌 정수이다. X는 주요한 버전이며, Y는 작은 버전, Z는 패치버전이다. 각 요소는 1씩 차례로 증가해야 한다.

• 상위 버전의 숫자가 올라갈 때 하위 버전의 숫자는 0으로 재설정되어야 한다.

• 버전 명이 주어진 패키지가 한번 공개되면, 해당 버전의 내용은 절대 수정되어선 안된다. 어떤 수정도 반드시 새로운 버전으로 공개되어야 한다.

• 주요 버전 0 (0.y.z)은 초기 개발을 위한 것이다. 언제든 변경될 수 있다. 공개 API는 안전하지 않다고 여긴다.

• 버전 1.0.0은 공개 API를 정의한다. 이 공개 이후의 버전 숫자가 바뀌는 방법은 공개 API와 변경 방법에 따라 결정된다.

• 정식배포전에 pre-release하는 경우에는 -또는 . 을 사용한다.

🌱 x.y.z 형식

• patch (x.y.Z x > 0)는 하위호환을 하지만 버그 수정이 있을 때 올라간다. 버그 수정은 내부적으로 잘못 처리되고 있는 것을 고치는 것을 의미한다.

• minor (x.Y.z x > 0)는 새로운 기능이 추가되었지만 기존의 공개 API가 하위호환되고 있을 때 올라간다. 공개 API가 하나 이상 deprecated될 시에도 올라가야 한다. 부가적인 새 기능이나 개선이 내부 코드 (private code)에 있을 시에도 올릴 수 있다. 이는 패치 수준의 변화를 포함할 수 있으나, 작은 버전이 올라가면 패치 버전은 꼭 0이 되어야 한다.

• major (X.y.z X > 0)는 하위호환되지 않는 변화가 추가될 때 반드시 올라가야 한다. 이는 패치 수준과 작은 수준의 변화를 포함할 수 있으나, 주요 버전이 올라가면 작은 버전과 패치 버전은 꼭 0이 되어야 한다.

🌲 범위 지정 명시자 (~, ^)

🌱 틸드 범위(~)

Minor version이 지정되어 있다면 patch level 변경을 허용한다.
Minor version이 지정되어 있지 않으면 minor-level 변경 또한 허용한다.

~1.3.2 : minor version이 지정되어 있으므로 patch level 변경을 허용한다.
~2: minor version이 지정되어있지 않으므로 minor- level변경을 허용한다.

🌱 캐럿범위(^)

0이 아닌 처음 버전 요소의 하위 버전을 수정할 수 있다.

1.0.0버전이면 minor, patch level 버전 업데이트 허용
0.X 버전이면 patch level 업데이트 허용
0.X.X버전이면 업데이트 허용하지 않음

추가로 major version이 0으로 시작하는 경우는 아직 1.0.0이 정식으로
릴리즈된게 아니기 때문에 0.1과 0.2 사이에 호환성이 손상되는 변경(breaking-change)이 발생할 수 도 있습니다.

🌱 Reference

• spoqa 기술 블로그
• iamjoo님의 velog