Semantic Versioning - MAJOR, MINOR, PATCH와 명세에 관하여

회사내에 오픈소스들을 개발하는데 SemVer를 아냐는 질문을 받았다.
🤦‍♀️ 더이상 들어만 봤다곤 할 수 없고 제대로 알지 않으면 항상 나중에 문제가 된다.
이런 이유로 공부하게 되었다. (이제 하나씩 채워가는 중이다.)

또한
package.json 파일에서

"devDependencies": {
  "react-test-renderer": "^16.13.0",
}

16.13.0 버전을 나타내는 점과 숫자들을 봤을 것이다. 이것 하나하나가 명세에 맞추어 업데이트가 되는데 어떻게 되는지 확인해보자.

[MAJOR , MINOR, PATCH] 로 구성되어 있다.

소프트웨어 릴리즈 버전 넘버에 대한 네이밍 시스템이다.

그라바타(Gravatars)의 창시자이자 깃헙(GitHub)의 공동창업자인 톰 프레스턴-베르너(Tom Preston-Werner)가 작성했으며, 오픈소스 프로젝트에 일반적으로 사용된다.버전은 사용자가 이 package (api)가 어떤식으로 변경되었는가를 이해할 수 있게 해준다.

Versions

• MAJOR Version: 기존 api가 변경 / 삭제 되었기 때문에 update 하면 동작하지 않을 수 있다는 경고의 의미
• MINOR Version: 이전 버전과 호환되는 방식으로 API가 추가되었으니 살펴보라는 의미
• PATCH Version: 이전 버전과 호환되는 버그 수정을 했을 경우

Semantic Versioning Specification (SemVer)

명세에 관해서는 페이지에서 확인하고 여기선 간략하게만 정리

https://semver.org/lang/ko , https://semver.org 영어로 보면 강조표시가 더 잘보인다.

• SemVer(유의적버전)을 쓰는 소프트웨어는 반드시 공개 API를 선언한다. 코드자체로 선언하거나, 문서로 엄격하게 명시해야 한다. (책임감 있는 개발자..)
• Normal Version은 반드시 X.Y.Z 형태이며 음수가 아닌 정수여야 하며 절대 앞에 0이 붙으면 안되고 각 수는 증가하는 수여야 한다.
• 배포하면 그 버전의 내용은 절대 변경해서는 안된다. 😱
• 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다.
• 1.0.0 버전은 공개 API를 정의한다. 이후 버전은 배포한 공개 API에서 어떻게 바뀌었는지에 따라 올린다.
• MAJOR Version이 올라가면 MINOR Version과 PATCH Version은 0이 되야하고
  MINOR Version이 올라가면 PATCH Version이 0이 반드시 되어야 한다.
• 정식 배포를 앞둔 pre-release version은 PATCH Version 바로 뒤에 붙임표(-)와 마침표(.)로 구분된 식별자를 더해서 표시할 수 있다. 식별자는 반드시 아스키(ASCII) 문자, 숫자, 붙임표로만 구성한다[0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 숫자 식별자의 경우 절대 앞에 0을 붙인 숫자로 표기하지 않는다.
  예) 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
  우선순위는 1.0.0-alpha < 1.0.0.
• Build metadata는 수버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현할 수 있다.
  Build metadata.. Build metadata.. ??🧐가 무엇일까?
  git commit 후 생기는 난수가 붙는 경우가 있는데 그 상태로 그대로 배포하는 경우 build metadata가 그것이였다.
  예) 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

"devDependencies": {
  "react-test-renderer": "^16.13.0",
  "react-zeroconfig": "^3.27.2-alpha.2"
}

Node에서는 Version Range를 권장하는데...
이러한 설명은..2탄에서..