티스토리 뷰
안녕하세요 :) 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가 붙는..
(제가 말하는게 정석이다!!이건 절대 아니에요)
뭘 의미하는지 더 자세하게 알아봅시다.
라고 해요. 조금 더 설명을 하자면,
아예 싹~ 바뀐 경우. 대규모 업그레이드가 이루어진 경우.
서버의 경우엔 클라이언트는 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님 블로그에서 재밌는 걸 봤는데,
출처
http://seorenn.blogspot.kr/2012/02/version.html
http://han41858.tistory.com/22
http://jinnydown.tistory.com/archive/201703
'공부' 카테고리의 다른 글
전달인자(Argument) VS 매개변수(Parameter) (0) | 2018.01.26 |
---|---|
코드사이닝? 인증서? 프로비저닝?? (3) | 2018.01.21 |
Xcode9 ) ambiguous use of 'filter' (0) | 2017.12.08 |
왕초보를 위한 <Reactive programming이 뭔지 알기 전에> (11) | 2017.11.24 |
Xcode ) Playground에 3rd party framework 추가하는 방법 (6) | 2017.11.22 |
- Xcode
- WWDC
- np-complete
- swift 공부
- SwiftUI
- UIBezierPath
- swift sort
- swift3
- Swift
- 스위프트 문법
- 피아노
- FLUTTER
- Accessibility
- WidgetKit
- 제이슨 파싱
- WKWebView
- swift array
- 스위프트
- fastlane
- swift tutorial
- IOS
- 회고
- swift delegate
- Git
- github
- actor
- ios 13
- Combine
- np-hard
- iOS delegate
- Total
- Today
- Yesterday