최근, 멘토님에게 포폴 첨삭을 받고있습니다. 포폴 첨삭을 받던중, 버전 규칙에 대한 지식이 부족한거같아 그 부분에 대해서 좀 알아보았어요... (다행히 기존 버전 관리도 나름 잘 해왔다... ㅋㅋ)
다음 사진은 크롬의 SW 버전입니다. 이 버전 규칙은 흔히 우리에게 익숙한 방식입니다.
이 익숙한 방식은 바로 Semantic versioning이라는 규칙에 따른 버전 명명 방식입니다.
Major.Minor.Patch
Semantic versioning 은 이런 형식을 가지고있습니다. (그리고 위에서 봤던 크롬의 처럼 Patch 뒤에 Build 라는 자리수가 더 오는 경우도 있다고 하네요.)
각각 Major, Minor, Patch는 어떻게 숫자를 올려야 하는지 설명드리겠습니다.
일반적 규칙
1. 버전 번호는 Major, Minor, Patch 의 형태로 배포하고, Major, Minor, Patch 는 각각 자연수이고 절대 앞에 0이 붙어서는 안된다.
2. 각 번호의 수는 항상 증가해야 한다.
3. 특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
4. Major 버전이 변경될 때, Minor, Patch 는 0으로 초기화 된다.
5. Minor 버전이 변경될 때, Patch 는 0으로 초기화 된다.
Major 버전 증가
1. 하위 버전과 호환되지 않는 변화가 생겼을 때
2. 대대적인 변화가 일어났을 때
3. 클라이언트가 기존 버전의 API 접근 방식으로 새 버전에 접속할 수 없을 때
Minor 버전 증가
1. 하위 버전과 호환이 되면서, 새로운 기능이 추가 될 때
2. 새로운 기능이 추가된 API 가 나왔지만, 기존의 공개된 API 가 하위 호환되고 있을 때
3. 기존의 기능이 변경되거나 사용 방법이 변경 되었을 때
Patch 버전 증가
1. 버그 수정
2. 기존 클라이언트가 알아차리지 못할 정도의 작은 변화가 있을 때
3. 서버 코드 내부적으로 소스가 수정되었을 때
4. 이 모든 것들이 하위 버전과 호환될 때
요약
1. 기존 버전과 호환되지 않게 API가 바뀌면 Major를 올린다.
2. 기존 버전과 호환되면서 새로운 기능을 추가할 때는 Minor를 올린다.
3. 기존 버전과 호환되면서 버그를 수정한 것이라면 Patch를 올린다.
참고