«   2018/08   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Tags
more
Archives
Today
0
Total
1,345
관리 메뉴

피아노 치는 개발자

버전 관리, 어떻게 해야할까? 본문

개발/일반

버전 관리, 어떻게 해야할까?

Claude.Seo 2017.02.17 23:05

버저닝(Versioning)

수많은 사람들이 자신이 만든 기술들을 배포하고 공유함으로써, 다른 사람들은 기능을 추가로 만들지 않고 손쉽게 가져와 재활용하여 소프트웨어를 손쉽게 만들 수 있게 됐다.


이러한 관계에서 기존 기술 개발자가 업데이트(수정, 추가, 삭제 등)할 경우, 이를 사용하는 다른 소프트웨어들은 정상적으로 동작할 수 없는 문제가 발생하게 된다.

위의 문제를 해결하기 위해 기존 기술과 새로운 기술을 구분할 수 있는 '버전'이라는 개념을 사용하기 시작했다



Semantic Versioning 2.0.0

버전 관리를 시작하면서 많은 문제를 해결해주었다. 하지만, 각각 사용하는 버전 관리 표기법이 달랐기 때문에 개발자들은 버전을 보고 의미를 해석하기 어려웠다.

이런 버전 관리 표기법을 통일하기 위해 Github의 공동 창업자인 `Tom Preston-Werner`는 기존 안들을 모아 Semantic Versioning을 제안했다.

이는 버전 형식에 의미를 부여하여 체계적인 버전 관리를 하기 위한 제안이며, 버저닝에 대한 명확한 의미를 부여한다.



요약

버전을 Major, Minor, Patch로 구분하며, 각 자리는 양의 정수로만 구성된다.

1. Semver를 쓰는 소프트웨어는 반드시 공개 API를 선언해야 한다. 이 API는 코드 자체로 선언하거나, 문서로 명확하게 선언되어야 한다. 어떤 방식으로든 정확하고 명확하게 선언되어야 한다.

2. 기존 버전과 호환되지 않으면 Major를 올린다.

3. 기존 버전과 호환되면서 새로운 기능을 추가했을 경우 Minor를 올린다

4. 기존 버전과 호환되면서 버그를 수정한 것이면 Patch를 올린다

5. 정식 버전 전, 혹은 메타 데이터를 위해 라벨을 붙일 수 있다. (ex. 0.9.9-alpha. 1)

6. Major 버전이 올라갈 경우 Minor, Patch 버전은 0으로 초기화 되어야 하며, Minor 버전이 올라갈 경우 Patch 버전은 0으로 초기화되어야 한다

7. 한번 버전이 결정되어 패키지가 배포되면, 어떠한 일이 발생하더라도 절대 수정하면 안 된다.


버전은 X.Y.Z 형태로 정의되어야 하며, 각 버전은 양의 정수로만 구성되어야 한다. 또한, 각 요소는 앞에 0이 붙을 수 없으며 각 요소는 1씩 증가해야 한다.

위의 규격대로 버전 관리를 하게 되면 각 요소의 숫자를 보고 변동 정도를 파악할 수 있게 된다.

만약 기존에 사용하던 라이브러리가 1.8.1 이였다고 가정을 했을 때, 1.8.2로 업데이트가 되었다면 소소한 버그 패치가 되었다고 볼 수 있으며, 1.9.0으로 업데이트가 되면 기존 버전과 호환되면서 새로운 기능이 추가했으니 검토가 필요하며, 2.0.0으로 업데이트되었을 경우 기존 버전과 호환되지 않으니 세밀한 검토가 필요하다고 볼 수 있다.



마무리

Semver는 혁신적인 제안은 아니지만, 버전 관리에 대한 통일된 규격을 제안함으로써 많은 문제를 해결하고 개발자에게 편의를 제공한다.

개인적으로 항상 버전 관리를 어떻게 해야 할까 고민하며 주변 지인들에게 물어봐도 뜬구름 잡기식으로 설명받았던 것들을 정확하게 알고 나니 훨씬 버전 관리에 대한 부담이 줄어들었다.

위의 내용은 공식 문서를 읽으면서 요약한 것이므로 공식문서를 읽어보면 더 자세하게 알 수 있다.



참고자료

Semver [ http://semver.org/ ]

0 Comments
댓글쓰기 폼