소프트웨어 버전 규칙

소프트웨어나 라이브러리, 프로젝트를 개발하다 보면, 버전을 어떻게 입력하고 업데이트를 해야 하나 고민한 경험이 있을 거에요.

저 또한, 그런 고민을 하고 있기에 버전에 관한 규칙을 알 수 있는 소프트웨어 버전 규칙에 대해 알아봅시다!

 

---

1. 소프트웨어 버전 규칙

소프트웨어 버전 규칙은 SemVer를 따릅니다. 이 때, SemVer는 Semantic Versioning의 줄임말로, SW의 호환성 및 변경 사항을 쉽게 파악할 수 있게 해주는 체계에요.

 

---

2. 버전 표기

버전 표기는 보통 주버전(Major), 부버전(Minor), 수정버전(Patch)의 세 사지 숫자로 구성되며, 특정 조건에 따라 숫자가 증가해요.(ex: 1.5.9)

 

2-1. 주버전 (Major Version)

주버전은 이전 버전과 호환되지 않는 큰 변화가 있을 때,증가합니다.

보통 API가 크게 변경되거나, SW의 주요 구조가 변경되어 구 버전과의 호환성이 사라질 때, 증가해요.

예를 들어, 데이터 구조 변경, 주요 기능의 삭제, 보안 모델 변경 등 중요한 수정이 포함될 때, 주버전이 올라갑니다.

ex : 1.0.0 → 2.0.0

 

2-2. 부버전 (Minor Version)

부버전은 이전 버전과 호환되는 새로운 기능이 추가될 때, 증가해요.

기존 기능에는 영향을 주지 않고, 새로운 기능을 추가하거나 SW를 개선하는 데 중점을 둡니다.

예를 들어, 새로운 API 메서드 추가, 성능 최적화, 새로운 옵션 추가 등이 포함됩니다.

부버전이 올라가면 개발자와 사용자는 기존 기능을 그대로 사용할 수 있으며, 필요에 따라 새로운 기능을 활용할 수 있어요.

ex : 1.0.0 → 1.1.0

 

2-3. 수정버전 (Patch Version)

수정버전은 버그 수정 or 사소한 변경사항이 있을 때, 증가해요.

주요 기능에는 변경이 없고, 버그 수정 or 성능 개선에 중점을 둡니다.

예를 들어, 버그 수정, 메모리 최적화, 보안 패치 등이 포함될 수 있어요.

이 버전 업그레이드는 안정성을 높이기 위한 것이며, 주로 기존 기능을 개선하고 오류를 해결하는 데 목적을 두고 있습니다.

ex : 1.0.0 → 1.0.1

 

---

3. 추가 태그

SemVer는 정식 버전 외에도 특정 태그를 붙여, 출시 전 상태를 명시할 수 있어요.

• 알파(alpha) : 초기 개발 단계의 버전입니다. 기능이 완성되지 않거나 불안정할 수 있어요. (ex: 1.0.0-alpha)
• 베타(beta) : 알파보다 안정적이지만, 여전히 테스트가 필요한 상태에요. 기능이 대부분 완성되었으나, 예상치 못한 버그가 존재할 수 있습니다. (ex : 1.0.0-beta)
• 릴리즈 후보(rc, release candidate) : 최종 버전 전의 후보로, 배포 준비가 거의 완료된 상태를 의미해요. 큰 문제가 없다면, 이 버전 그대로 정식 출시됩니다. (ex : 1.0.0-rc.1)

 

---

4. 소프트웨어 버전 규칙의 장점

그러면 이렇게 규칙을 확인해 가면서 버전을 올리는 이유는 무엇일까요?

우선, 호환성 관리에 좋습니다. 각 버전에서 호환성 여부를 쉽게 판단할 수 있어, 개발자와 사용자 모두 코드 수정이 필요한 지 판단하기 쉬워집니다.

또한. 각 버전 증가의 의미가 명확해져, 버전을 통해 어떤 변화가 있었는 지 명확한 의미 전달이 가능해요.

그리고 버그 수정이 주기적으로 이루어지는 것을 버전으로 쉽게 확인할 수 있으며, 안정적인 SW 개발을 유지할 수 있어요.

 

---

5. 정리하며

지금까지 소프트웨어 버전 규칙에 대해 알아보았습니다.

SemVer의 공식 홈페이지도 있으니, 참고하시면 좋을 것 같아요!

 

참고

semver 공식 홈페이지

kiwinam 님의 Software 버전 관리 규칙, 너만 모르는 Semantic versioning

goodjam92 님의 Semantic Versioning - 버전 관리(규칙)