개발자들은 어떻게 버전을 표기할까? SemVer란 무엇일까?

개발자들은 어떻게 버전을 표기할까? SemVer란 무엇일까?

 

안녕하세요!

우리는 개발을 하면서 혹은 일상에서 버전에 관해서 많이 보고 들었습니다.

간단하게 자주 볼 수 있는 예를 제시하자면, 우리가 즐겨하는 게임을 실행하기 전 

우리는 v 13.8.2와 같은 영어 v와 함께 여러 숫자들이 나열되어있는 것을 한 번쯤은 보았을 것입니다.

우리는 이를 보고 이 게임의 버전이구나 하고 생각하지만, 과연 어떻게 이러한 숫자들이 어떤 규칙을 따르는 것인지

그리고 그 규칙 중 하나인 SemVer 즉 semantic version에 관해서 알아보겠습니다.

 

1. SemVer란?
2.  마치며

 

1. SemVer란?

 

SemVer란 Semantic Versioning의 약자로써 버전을 관리하는 형식 중 하나입니다.

많은 소프트웨워가 이러한 형식을 따르지만 꼭 모두 그런 것은 아닙니다.

 

대부분의 버전은 3가지의 숫자로 표시되며 이는 각각 점을 통해서 나뉘게 됩니다.

예를 들면 앞서 언급하였던 13.8.2가 될 수 있습니다. 이때 숫자의 제한은 없습니다.

자 그럼 왜 3가지의 숫자로 나뉘어있고, 각각 무엇을 의미하며 어떻게 사용되는지 알아보겠습니다.

 

이러한 숫자들은 Major, Minor, Patch를 각각 뜻하게 됩니다.

패치는 그럭저럭 감이 오지만 그렇다면 Major와 Minor는 무엇을 뜻하는 것일까요?

 

자 지금부터 알아보겠습니다.

 

Major: 메이저는 가장 큰 변화를 뜻합니다. 그 말은 즉 프로그램 혹은 라이브러리 등의 거대한 변화가 있으며,

이로 인해 예전에 작성되거나 사용 중에는 버전의 프로그램, 라이브러리 등이 새로운 버전을 적용 시 작동하지 않을 수 있을 정도의

큰 변화인 것입니다. 이때 중요한 것은 마이너와 패치의 숫자는 다시 0으로 초기화된다는 것입니다.

예를 들면 13.8.2 ->14.0.0과 같이 말입니다.

 

Minor: 메이저보다는 작은 변화를 말합니다. 이때 대부분 새로운 기능이 추가되었을때 마이너의 숫자가 올라가게 됩니다.

리액트를 예로 들어보면 페이스북에서 리액트 훅을 발표했을 당시 메이져 버전이 변경된 것이 아닌 마이너의 버전이 변경되었습니다.

이는 새로운 기능(feature)이기 때문입니다.

 

Patch: 이는 우리가 익숙하게 생각하는 버그 패치, 텍스트 변경 등등의 자잘한 패치들이 진행될 때 버전이 변경되게 됩니다.

 

이러한 변경점들은 몇 가지 규칙을 가지게 됩니다.

예를 들면 버전이 한 번에 2 혹은 3과 같이 올라갈 수 없습니다. 즉

13.8.2 -> 13.8.5로 껑충 뛰는 것은 불가능합니다. 항상 숫자는 1씩 올라가게 되어야 합니다.

또한 버전이 정해지게 된 후 업데이트가 잘못되었다는 것을 깨닫는다면 이때 버전을 돌리거나 바꿀 수 없습니다.

단지 다시 그 버그를 수정하여 그다음 버전으로 릴리스해야 합니다. 즉

13.8.2 ->13.8.3 패치 후 버그 발견 -> 버그를 수정한 후 13.8.4 버전으로 배포.

 

그렇다면 이러한 버전은 어떻게 하나하나 관리될까요??

사실상 개발자들조차 의식하고 알아차릴 수 있을까요?

정답은 네입니다. 이를 위해서 한 가지 모듈로 Semantic Release가 있습니다.

이는 버전의 변경에 따른 changelog의 변경과 배포를 도와줍니다.

이때 개발자는 깃을 통해 코드를 푸시할 때 커밋으로 몇몇 메시지를 남기게 됩니다.

예를 들면 fix, feature등과 같이 말입니다.

그렇다면 이를 통해 매니저는 새로운 패치, 업데이트가 있음을 감지하고 그에 상응하는 새로운 버전을 만든 후 배포합니다.

 

 

2. 마치며.

 

오늘은 짧게 버전에 관해 알아보았습니다.

사실 혼자서 자유롭게 프로젝트를 진행하다 보면, 버전 관리는 소홀해지기 마련이고, 그냥 읽기 쉽고 편하게

또한 다른 Branch 없이 master에 직접 코드를 푸시하고 간단하게 사용하기 마련입니다.

하지만 실제 협업에서는 이러한 작업방식은 모두를 난해하게 만들고 실수를 유발하기 마련입니다.

 

또한 회사는 각각의 라이브러리 혹은 모듈을 가지고 있는 경우도 있습니다.

이러한 모듈은 모든 개발자들이 공유해서 사용하는 경우가 많기 때문에,

코드의 수정이 있다면 그에 상응하는 버전을 항상 관리해주어야 합니다.

 

처음은 이해하기 힘들고 새로운 버전을 배포하기까지 실수는 하지 않았는지, 제대로 커밋을 했는지 

많은 고민을 하게 될 것이지만 적응이 되면, 왜 버전이 관리되어야 하는지, 어떤 버전에 어떤 기능과 패치들이 존재하는지,

더 자세하고 쉽게 이해할 수 있을 것입니다.

 

다음은 실제 협업을 할 때 깃으로 어떻게 작업을 하는지 짧게 알아보겠습니다.

또한 많이 사용되는 커맨드들은 어떤 것들인지 역시 알아보겠습니다.

 

오늘도 제 블로그를 방문해주셔서 감사합니다.

저는 깊은 지식은 아니지만 이해하기 쉽고 머리에 많이 남을 핵심들을 게시글에 작성하려 노력하고 있습니다.

오늘도 여러분의 코딩을 응원하며, 즐거운 코딩하시기 바랍니다.

감사합니다.

 

완벽한 준비란 없다. 완벽한 준비란, 영원히 시작하지 않는 것과 같다.

Es gibt keinep perfekte Vorbereitung,

Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.