-
참고 문서
- Semantic Versioning
- Tilde (~) and Caret (^)
-
Semantic Versioning
- 소프트웨어 및 그 외 프러덕트에 버전 넘버를 표기하는 표준화된 방법
- 변경 사항 및 호환성에 대한 정보를 전달하기 위해 사용한다.
- 명확하고 논리적인 구조 덕분에 가장 많이 사용되는 방식이다.
- (그 외의 버전 관리 기법으로는 다음의 것들이 있으니 참고)
- Date-Based Versioning
- Sequential Versioning
- Calendar Versioning
- Alphabetical Versioning
- Hybrid Versioning
-
사용 의의
- 변경 사항과 진척 사항을 추적할 수 있도록 한다.
- 일반 사용자 입장에서 업데이트의 중요성을 판단할 수 있다.
-
Major.Minor.Patch 형식
- Major
- 호환되지 않는 변경 사항이 코드에 도입될 때 추가된다.
- 예시
- Python 2에서 작성된 코드가 Python 3 인터프리터에서 실행 불가한 경우
- 프론트 앱의 UI/UX가 완전히 리뉴얼되어 기존의 앱 사용 시나리오 사용이 불가한 경우
- 인증 절차가 완전히 바뀌어 기존의 토큰, 세션이 무효화 된 경우
- 특정 OS 버전에서 앱 지원을 종료하여 호환성이 깨져버리는 경우
- Minor
- 호환성을 유지한 상태에서 기능이 추가될 떄 증가한다.
- 예시
- Python 3에 새로운 API 추가
- 모바일 앱에 새로운 화면 추가
- Patch
- 버그 수정 및 마이너한 업데이트가 적용될 시 증가한다.
- 새로운 기능을 추가하지는 않는다.
- 예시
- 버그 픽스
- 오타 수정
- 레이아웃 미세 조정
- 코드 최적화 및 성능 개편
- pre-release와 build metadata를 명시하기 위한 선택적 접미사도 존재한다.
- 안정적이지 않은 빌드의 경우, 하이픈을 사용해 알파벳으로 구성된 접미사를 붙여 사용한다.
- 빌드를 식별하기 위해 플러스 기호 뒤에 메타 데이터를 붙일 수 있다.
-
관행
- 마지막 릴리즈 이후의 커밋을 살펴본 후, 이후 릴리즈 타입이 어떻게 될지 결정한다.
- 호환성 깨짐 -> 메이저
- 새 기능 추가 -> 마이너
- 버그 수정 -> 패치
- GitHub 등의 도구를 사용해 릴리즈에 태그(tag)를 붙이도록 한다.
- 일반 사용자에게 어떤 변경점이 이뤄졌는지를 알리기 위해 Changelog 파일을 작성한다.
- 첫 버전은 보통 0.1.0 부터 시작한다.
- 1.0.0 이전은 개발 단계로 간주하며, API는 언제든지 바뀔 수 있다.
- 0.x.x 버전은 정식 범위에 포함되지 않기 때문
- 기능 추가, 소스 코드의 큰 구조가 변경될 시 minor를 업데이트 한다.
- 기능 추가 과정에서 발생한 버그 픽스가 이뤄질 시 patch를 업데이트 한다.
-
Tilde (~) and Caret (^)
- ~
- major/minor를 고정하고 patch의 자유로운 업데이트를 허용한다.
- ^
- major를 고정하고 minor/patch의 자유로운 업데이트를 허용한다.