Semantic versioning

안녕하세요 :) Zedd입니다.

2018년 새해가 밝았네요!!!!

그리고 오늘은 제가 이 블로그를 시작한지 1년이 되는날~.~ 키키 2018년에는 더 열심히 하는걸로..

아무튼 모두들 새해 복 많이 받으세요!!!! XD

오늘은 오늘 새벽에...궁금해진 Software versioning입니다.

엥;; 하실 분들도 계실텐데..제가 이 Software versioning에 대해서 정말 무지했었습니댜..

그래서 공부해볼려고해요 :)

Software versioning

---

궁금증은...Swift Korea슬랙에서 부터 시작됐습니다.

ㅇㅇㅇ??

수열님의 오픈소스 라이브러리 버전 현황인데요..

오픈소스니까..올려도 되는거 맞겠죠..? 문제되면 바로 지우겠습니다.

아무튼 이게 왜;;할 수도 있지만

수열님의

"릴리즈를 할 때 마다 major version이 올라가는 기이한 프로젝트" 

이 말에서 major version이 뭐지..?하고 위 그림을 봤는데, 버전이 3자리인거에요. 

딱봐도 Major버전이 맨 앞 자리라는 것을 알 수 있죠.

갑자기 머리속을 스쳐가는 앱들...

다 3자리네?

(그와중에 리니지2 레볼루션 버전 ㄷ ㄷ )

뭔가 컨벤션?..뭔가 약속 같은게 있는건가?

나는 1.1 -> 1.2 이런식으로 하고있는데...

뭐지..?하고 찾아봤더니

역시나

Software versioning....

그렇군요..이제 진짜로 Software versioning을 공부해봅시다.

보통 Semantic Versioning을 쓰는 것 같으니까 Semantic Versioning로 설명드릴게요!

X.Y.Z

이 있다고 생각해 볼게요.

그럼 .으로 나누어진 각 자리는 도대체!! 뭘 의미하는 걸까요?

Major.Minor.Patch

을 의미하는데, 3자리이상도 사용한다고 해요 :) Patch뒤에 .Build가 붙는..

(제가 말하는게 정석이다!!이건 절대 아니에요)

뭘 의미하는지 더 자세하게 알아봅시다.

이전(하위) 버전과 호환되지 않는 API 변경은 MAJOR 버전 증가 

이전(하위) 버전과 호환되면서, 동시에 기능의 변경, 추가된 경우는 MINOR 버전 증가

이전(하위) 버전과 호환되면서, 버그 수정은 PATCH 버전 증가

라고 해요. 조금 더 설명을 하자면,

MAJOR버전 증가 :

아예 싹~ 바뀐 경우. 대규모 업그레이드가 이루어진 경우.

서버의 경우엔 클라이언트는 1.X.X으로의 접속 방식을 2.X.X에는 절대 접속 할 수 없다는 얘기.

MINOR버전 증가 :

API 또는 기능에 변경이 발생되었을 경.

서버의 경우엔 기존 사용자들의 접속의 의사소통은 원할히 이루에 지지만, 몇몇 API가 추가/변경 되었거나 기능의 사용방법이 변경되었을 경우.

소통은 원할히 이루어지지만 몇몇 기능들은 불가능 할 것이다.

MINOR 버전이 변경되었을 경우엔 클라이언트에게 변경사항을 반드시 알려야 한다.

PATCH버전 증가 : 

버그 수정의 경우.

기존 클라이언트들은 접속과 수행에 아무런 변경사항을 느끼지 못한다. 2.1.3과 2.1.4를 동일한 방법으로 사용할 수 있다. 

하지만 서버 내부적으로는 버그가 수정되었거나, 내부적으로 소스가 수정되었다

그러나 클라이언트는 "뭔가 변경이 있었구나"정도로만 생각하면 될 뿐, 서버로의 접속에는 전혀 변경될 사항이 없다. 이 버전은 현재 날짜를 써도 된다

라고 해요.

그러니까 간단하게 요약하면 

걍 앱이 그냥 싹 바뀐 경우면 -> Major

기능 추가, 변경 -> Minor

버그수정 -> Patch

버전을 올리는 것입니다.

Semantic Versioning을 사용하는 룰?이 조금 있는데.

1. 버전번호는 반드시 .Y.Z의 형태로 하고, X, Y, Z는 각각 자연수(음이 아닌 정수)이고, 절대로 0이 앞에 붙어서는 안 된다.X는 Major버전 번호이고, Y는 Minor버전 번호이며, Z는 Patch버전 번호이다. 각각은 반드시 증가하는 수여야 한다. 예: 1.9.0 -> 1.10.0 -> 1.11.0.

2.특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야 한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.

3. Major버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 이 공개 API는 안정판으로 보지 않는 게 좋다.

4. 1.0.0 버전은 공개 API를 정의한다. 이후의 버전 번호는 이때 배포한 공개 API에서 어떻게 바뀌는지에 따라 올린다.

5. Patch버전 Z (x.y.Z | x > 0)는 반드시 그전 버전 API와 호환되는 버그 수정의 경우에만 올린다. 버그 수정은 잘못된 내부 기능을 고치는 것이라 정의한다.

6. 공개 API에 기존과 호환되는 새로운 기능을 추가할 때는 반드시 Minor버전 Y(x.Y.z | x > 0)를 올린다. 공개 API의 일부를 앞으로 제거할 것(deprecate)으로 표시한 경우에도 반드시 올리도록 한다. 내부 비공개 코드에 새로운 기능이 대폭 추가되거나 개선사항이 있을 때도 올릴 수 있다. 부버전을 올릴 때 Patch버전을 올릴 때만큼의 변화를 포함할 수도 있다. Minor버전이 올라가면 Patch버전은 반드시 0에서 다시 시작한다.

7. 공개 API에 기존과 호환되지 않는 변화가 있을 때는 반드시 Major버전 X(X.y.z | X > 0)를 올린다. Minor 버전이나 Patch버전 급 변화를 포함할 수 있다. Major버전 번호를 올릴 때는 반드시 Minor 버전이나 Patch버전을 0으로 초기화 한다.

이정도? 

ㅎㅎ..

그리고, Seorenn SIGSEGV님 블로그에서 재밌는 걸 봤는데,

Q. 1.3과 1.12 중 어느 버전이 더 최신 버전인가요?

A. 1.12가 더 최신버전입니다.

OTL 저 역시.....버전을 소수점으로 봤다는 것입니다.. 물론 "수학적인" 대소를 비교하면 1.3이 크지만 버전에서는 아닙니다. 애초에 X.Y.Z는 "소수"를 의미하는게 아니에요.

왜 1.12가 더 최신버전인지는 이 글을 참고하시면 될 것 같아요 :)

앞으로 버전관리를 신경써서 해야겠어요!!!!!!!!!

오늘도 도움이 되었길 바랍니다 ㅎㅎ 

새해 복 많이 받으세요!!!!!💕

출처

http://seorenn.blogspot.kr/2012/02/version.html

http://han41858.tistory.com/22

http://jinnydown.tistory.com/archive/201703

https://semver.org/lang/ko/