프로젝트 버전 관리

이번에 회사 업무를 처리함에 있어 프로젝트의 버전 정보가 정의 없이 이루어지는거 같아,

다음 프로젝트에 사용해보기 위해 이 글을 작성하고 정리하였습니다.

 

버전 관리를 하는 방식은 찾아보니까 정말 많이 있었습니다.

제가 느끼기에 그중 가장 익숙한 Semantic versioning을 정리해보았습니다. ( 이런 이름도 이번에 처음 알았습니다. )

 

소개 홈페이지 주소로는 https://semver.org/ 입니다.

 

Semantic versioning이란 

• Major, Minor, Patch 규칙으로 표기 하며 구글의 경우 뒤에 Build를 하나더 붙인다고 합니다.

 

규칙

1. 버전 번호는 Major, Minor, Patch 의 형태로 배포하고, Major, Minor, Patch 는 각각 자연수이고 절대 앞에 0이 붙어서는 안된다.  ( 각 번호의 수는 항상 증가해야 한다. )
2. 특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
3. Major 버전이 변경될 때, Minor, Patch 는 0으로 초기화 된다.
4. Minor 버전이 변경될 때, Patch 는 0으로 초기화 된다.
   
   

Major 버전 증가

1. 하위 버전과 호환되지 않는 변화가 생겼을 때
2. 대대적인 변화가 일어났을 때
3. 클라이언트가 1.0.0 버전의 API 접근 방식으로 2.0.0 버전에 접속할 수 없을 때
   
   

Minor 버전 증가

1. 하위 버전과 호환이 되면서, 새로운 기능이 추가 될 때
2. 새로운 기능이 추가된 API 가 나왔지만, 기존의 공개된 API 가 하위 호환되고 있을 때
3. 기존의 기능이 변경되거나 사용 방법이 변경 되었을 때
   
   

Patch 버전 증가

1. 버그 수정
2. 기존 클라이언트가 알아차리지 못할 정도의 작은 변화가 있을 때
3. 서버 코드 내부적으로 소스가 수정되었을 때
4. 당연한 얘기겠지만, 이 모든 것들이 하위 버전과 호환될 때

 

추가 규칙

1. Semantic Versioning을 쓰는 소프트웨어는 반드시 공개 API를 정의해야 한다. 이 API는 코드 자체에 정의되어 있거나 명시적으로 문서화 되어있어야 한다. 이 과정은 포괄적이며 정확해야 한다.
2. Major 버전 0 은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 이 공개 API 는 안정판으로 보지 않는 것이 좋다.
3. 1.0.0 버전은 공개 API 를 정의한다. 이후의 버전 번호는 이때 공개 API 에서 어떻게 바뀌는지에 따라 올린다.
4. Patch 버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 정식 배포를 앞둔 (pre-release) 버전을 표기할 수 있다.

 

저는 Git과 연동하여 빌드하면 버전이 자동으로 오르는 방식으로 고민해보았으나, 아직까지는 이 방식을 사용해야할 것 같습니다...

 

 

참고 출처

https://mrchypark.github.io/post/%ED%8C%A8%ED%82%A4%EC%A7%80-%EB%B2%84%EC%A0%84%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9E%91%EC%84%B1%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C/

mrchypark: 패키지 버전은 어떻게 작성해야할까

https://kiwinam.com/posts/33/version-naming/

Software 버전 관리 규칙, 너만 모르는 Semantic versioning :: 키위남