소프트웨어 버전 관리 규칙 - Semantic Versioning
1. 들어가며
Github에는 위와 같이 Releases라는 기능이 있어 소스코드의 결과물을 배포할 수 있는 기능을 제공하고 있다.
이전에는 해당 기능을 사용하지 않았지만, 이번 프로젝트부터는 릴리즈를 배포하여 서버의 버전을 제대로 관리해보고자 한다.
이번 포스트에서는 버전 관리에 앞서 버전을 작성하는 방법을 알아보자.
2. 버전 관리가 왜 필요한가?
버전 관리를 통해 우리는 아래와 같은 이점을 얻을 수 있다.
- 히스토리 추적 및 관리
- 백업 및 복구 용이
- 사용자에게 버전에 대한 정보 제공
3. Semantic Versioning
앱이나 게임을 보면 v.1.6.2 처럼 버전이 적힌 것을 볼 수 있다. 하지만 이런 버전은 개발자가 임의로 적는 것이 아니라는 사실 ...!!!
저런 형태의 버전은 Semantic versioning 이라는 규칙을 따른 버전 이름이고, 대부분의 소프트웨어가 Semantic versioning 방식으로 버전을 표기한다.
Semantic Versioning은 .으로 구분되는 3개의 숫자로 이루어져 있다. 각 버전을 어떻게 사용하는지에 대해 내가 좋아하는 게임인 젤다 왕눈을 예시로 들며 소개하겠다. (***실제 게임과는 관련이 전혀 없는 허구의 예시입니다)
Semantic 버전의 각 숫자는 Major 버전, Minor 버전, Patch 버전을 의미한다.
Major Version
첫 번째 숫자는 Major 버전으로 이전 버전들과의 호환성을 나타내며 아래와 같은 상황일 때 버전을 증가시킨다.
- 이전 버전과 호환되지 않는 큰 변화가 있을 때
- 대대적인 변화가 일어났을 때
- 이전 Major 버전의 API 접근 방식으로 현재 버전에서 접근이 불가능할 때
최종 보스인 가논에게 치명적인 버그가 생겨서 최종 보스를 바꿔야 하는 크리티컬한 이슈가 생겼다고 해보자 !!!
이럴 경우는 게임에 대대적인 변화가 생기는 것이기 때문에 Major 버전을 증가시켜야 한다.
Minor Version
하위 버전과 호환이 되면서 새로운 기능이 추가되거나 변경되었을 때 올려준다. Major 버전과 다르게 이전 버전과 호환되는 새로운 기능이 추가되었을 때 올려준다.
만약 이번 버전에서 새로운 무기로 마법소녀봉이 추가되었다면 이는 하위 버전과 호환되면서 새로운 기능이 추가된 것이기 때문에 Minor 버전 업데이트에 해당한다.
Patch Version
버그 수정, 내부적인 코드 변경 등 사용자가 알아차리지 못할 작은 변화가 있을 때 올려준다. Minor Version과 마찬가지로 변화가 하위 버전과 호환이 가능해야 한다.
만약 츄츄의 리젠 로직이 메모리를 많이 소모하였지만 이를 개선하여 게임의 사용성을 개선했다면 Patch 버전 업데이트가 되는 것이다.
현재 버전을 2.6.8이라고 가정했을 때 위에서부터 순서대로 Patch, Minor, Major 버전을 업데이트했을 때의 예시이다.
4. 일반적인 규칙
이 외에 버저닝에 적용해야 하는 일반적인 규칙은 아래와 같다.
- 첫 버전은 0.1.0으로 시작한다.
- 소프트웨어가 실 서비스에 사용되는, 사용자들이 믿고 쓸 수 있는 안정적인 상태라면 1.0.0이 될 수 있다.
- 특정 버전을 배포하고 나면 그 버전의 내용은 절대 변경하지 말아야 한다. 변경 사항이 있다면 반드시 새로운 버전으로 배포하도록 한다.
- Major 버전이 변경될 때 Minor, Patch는 0으로 초기화한다.
- Minor 버전이 변경될 때 Patch는 0으로 초기화한다.
5. 마치며
Semantic Versioning에 대해 소개하는 공식 홈페이지도 있으므로 아래 링크를 읽어보면 더욱 도움이 될 것이다.
유의적 버전 2.0.0
Semantic Versioning spec and website
semver.org