유의적 버전 - Semver

프로젝트를 관리하기위해서 여러가지 방법을 사용하지만
그중에 가장 많이 보이는건 1.0.3 과 같이 숫자 3개를 . 을 이용해 구분하는 방법일것이다.
대표적으로 Node.js의 package.json 에 있는 version이다.
코드를 보면

{
  "name": "project-name",
  "version": "1.0.3",
  "description": "project-description",
  "repository": {
    "type": "git",
    "url": ""
  }
  ...
}

과 같이 표현하고 있는것들을 확인할 수 있다.
또한 많은 오픈소스들이 이와같은 형태로 버전을 구분하고 있다.

가끔 어떤 프로젝트에선 버전업을 적당히 숫자3개중 골라서 올리기도 하지만 그렇게 해서는 버전이 올라간것을 보고 어떻게 변경됬는지 추축할 수 없다.

요즘에 프로젝트를 할때 이것저것 오픈소스를 많이 가져다가 사용하는데 그때마다 버전이 올라가면 의존성이 깨지는지 확인해야한다. 이게 글로만 보면 별거 아닌 문제처럼 보일지 모르겠지만 엄청 귀찮은 문제이다.
따라서 버전만 보고도 의존성이 깨질지 깨지지 않을건지, 어떤 부분이 개선되거나 추가됬는지 알 수 있어야한다.

이러한 문제점을 해결하기 위해서 버전을 3개로 나누고 각각 버전업이 될때 의미를 부여하였다.


일단 버전은 3개로 나뉘는데 다음과 같다.

MAJOR  .  MINOR  . PATCH 

MAJOR버전은 기존 버전과 호환되지 않게 API가 수정되면 버전업한다.
MINOR  버전은 기존 버전과 호환되면서 새로운 기능을 추가됬을 때 버전업한다.
PATCH 버전은 기존 버전과 호환되면서 버그를 수정했을 때 버전업한다.


기본적으로 위에 3가지 규칙을 기반으로 버전을 올린다.

이 외에 규칙으로는 다음과 같은것들이 있다.

1. Semver를 사용하는 프로젝트는 공개 API를 선언해야한다. 이를 코드로 명세하던 문서로 명세해야한다.
2. 버전은 음이아닌 정수로 x.y.z 로 선언해야하고, 각각 x는 Major, y는 Minor, z는 Patch버전이다. 
3. 버전은 만드시 증가해야한다.
4. 특정 버전으로 배포하면 그 버전은 변경되선 안된다. 변경부분이 있다면 반드시 새로운 버전으로 배포해야한다.
5. 1.0.0버전은 공개API를 정의한다. 이후에 버전은 1.0.0버전을 기준으로 측정한다.
6. 상위 버전이 올라간경우 하위버전은 0으로 설정한다.
7. patch버전 위에 - 나 . 을 통해 pre-release를 명시할 수 있다. 

이것 외에도 더 많은 규칙들이 있고 자세하게 나와있는 문서가 있다.
http://semver.org/lang/ko/ 
번역도 되어있으니 참고하면 좋을것같다.

하지만 이러한 규칙도 자신의 프로젝트 상황에 맞춰서 해야된다고 생각한다.
너무 규칙에 얽매이지 말고 상황에 맞춰서 적용시켜보자.