유의적 버전 작성하기

소프트웨어를 관리하다 보면 버전을 부여하게 된다.

진짜 리얼 팩트 찐최종...

( 출처: tvn페이스북 페이지 )

가령 이렇게 끝없이...네이밍을 하는 경우가 정말 많다. (필자도 이렇게 쓴 적이 많다.)

그러나 어떤 파일이 어느 내용을 담고 있는지 모르기 때문에 관리하기가 정말 힘들다. 저기서 정말 최종본이 무엇인지 조차 알 수 없다!!

그래서 필수는 아니지만 버전이 엉키는 걸 방지하고 관리하기 위해 제안사항으로 많은 사람들이 유의적 버전을 사용하고 있다.

유의적 버전

 간단하게 말하자면 버전을 주.부.수 숫자로 표현할 수 있다. (ex. 1.3.1)

1. 주 버전(MAJOR) : 기존 버전과 호환이 되지 않게 변경이 되면 주 버전을 변경한다.

2. 부 버전(MINOR) : 기존 버전과 호환이 되면서 새로운 기능을 추가한 경우 부 버전을 변경한다.

3. 수 버전(PATCH) : 기존 버전과 호환이 되면서 버그를 수정한 경우 수 버전을 변경한다.

주.부.수 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다. (ex. 1.0.0-alpha 등)

예를 들어 1.0.2 버전보다 1.1.0 버전이 이후 버전이고, 1.1.0 보다는 1.1.2가 이후 버전이다! 당연히 2.0.0은 1.1.2보다 나중 버전이다!

 좀 더 상세한 유의적 버전 작성법은 다음과 같다.

1. 유의적 버전을 쓰는 소프트웨어는 반드시 공개 API를 선언한다.

2. 보통 버전의 번호는 반드시 X.Y.Z의 형태로 하고, 각각 자연수이고 0이 앞에 붙어서는 안되며 반드시 수가 증가하여야한다.

3. 특정 버전으로 패키지를 배포하면 내용은 절대로 변경해서는 안된다. 변경사항은 새로운 버전으로 배포한다.

4. 주버전 0(ex. 0.y.z)은 초기 개발을 위해서 쓴다.

5. 1.0.0 버전은 공개 API를 정의한다.

6. 수버전 Z는 반드시 그전 버전 API와 호환되는 버그 수정의 경우에만 올린다.

7. 공개 API에 기존과 호환되는 새로운 기능을 추가 및 제거 때는 반드시 부버전을 올린다. 부버전이 올라가면 수버전은 0에서 다시 시작한다.

8. 공개 API와 호환이 되지 않는 변화가 있을 때는 반드시 주버전을 올린다. 마찬가지로 부버전과 수버전을 0으로 초기화 시킨다.

9. 수버전 바로 뒤에 붙임표를 붙이고 마침표로 구분된 식별자를 더해서 정식 배포를 앞둔 pre-release버전을 표기할 수 있다.

 - 식별자는 반드시 아스키문자, 숫자, 붙임표로만 구성한다.

10. 빌드 메타데이터는 수버전이나 정식배포 전 식별자 뒤에 더하기 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현할 수 있다.

11. 우선순위는 버전의 순서를 정렬할 때 서로를 어떻게 비교할지를 나타낸다. 우선순위는 반드시 주, 부, 수 버전, 그리고 정식배포 전 버전의 식별자를 나누어 계산하도록 한다. (빌드 메타데이터는 우선순위에 영향을 주지 않는다.) 정식배포 전 버전이 표기된 경우의 우선순위가 더 낮다.

더욱 자세한 내용은 아래 링크에서 확인할 수 있다!

출처 : https://semver.org/lang/ko/