티스토리 뷰

공부

Semantic versioning

Zedd0202 2018. 1. 2. 15:38
반응형

안녕하세요 :) 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/








    반응형