혹시 그거 아세요?

버전을 정하는데에도 규칙이 존재한다는 사실요.
저는 사실 그냥 무지성 1.0.0 으로 시작해서 맨 오른쪽 숫자만 +1씩 증가시켜주는 방향으로 진행했어요.

근데 이번에 버전을 어떻게 정하고 어떻게 관리하는가에 대해 알게되어서, 알게된 김에 정리해보겠습니다.

시맨틱 버전 관리(Semantic Versioning)

소프트웨어 개발에서 버전 관리는 매우 중요한 요소입니다. 특히 협업 환경이나 사용자와의 소통에서 버전 번호만 보고도 변경 사항의 크기와 중요도를 알 수 있다면, 훨씬 효율적으로 소프트웨어를 관리할 수 있습니다. 이를 위해 대부분이 시맨틱 버전 관리(Semantic Versioning, SemVer) 규칙을 사용합니다.

시맨틱 버전 관리의 구조

버전 번호는 다음과 같은 형식으로 구성됩니다:

MAJOR.MINOR.PATCH

대충 1.0.0 으로 생각해보면 1은 major, 중간의 0은 minor, 끝의 0은 patch라고 생각해주시면 되겠습니다.

MAJOR (주 버전)

호환되지 않는 중대한 변경이 발생했을 때 변경됩니다.

• 기존 API가 변경되어 이전 버전과 호환되지 않을 때.
• 기존 기능이 제거되거나, 소프트웨어 아키텍처가 완전히 개편될 때.

ex.
1.0.0 → 2.0.0: 기존에 제공하던 기능이 대거 변경되거나 삭제됨.

MINOR (부 버전)

새로운 기능이 추가되었지만, 이전 버전과 호환성은 유지될 때 변경됩니다.

• 새로운 기능 추가 (기존 기능에 영향을 주지 않음).
• 기존 API에 옵션이나 속성이 추가됨.

ex.
1.0.0 → 1.1.0: 새로운 검색 필터 기능 추가.

PATCH (수정 버전)

버그 수정, 성능 개선, 보안 패치 등 소규모 수정이 이루어졌을 때 변경됩니다.

• 기능에는 변화가 없지만, 안정성을 높이기 위한 수정.
• UI/UX 세부 조정.

ex
1.0.0 → 1.0.1: 로그인 기능에서 발생하던 특정 버그 수정.

0.0.0과 1.0.0

최초로 개발을 진행할 때는 0.y.z로 시작합니다. 초기 개발을 위해 사용하는 0.y.z은 편할대로 바꿔도 무방 합니다.

초기 개발 단계에 0.y.z 버전 관리는 어떻게 해야 할까?

가장 간단한 방법은 최초 개발 배포를 0.1.0으로 하고, 이후 배포마다 부버전을 올리는 것입니다.

그럼 언제 1.0.0이라고 할 수 있을까?

소프트웨어가 실 서비스에 쓰이기 시작했다면 이미 1.0.0이라고 여길 수 있습니다.

사용자들이 믿고 쓸 수 있는 안정한 API가 있다면 -> 1.0.0

하위 버전 호환성에 대해 우려하기 시작했다면 이미 1.0.0일 수 있습니다.

이 이외에도 아스키코드, pre-release, 우선순위 등등 다양한 방법이 있지만 다른 블로그에서 더욱 디테일하게 설명해주기 때문에, 아 이런 규칙이 있구나 하고 간단하게 정리하면서 마무리 해보겠습니다.

정진!