http://semver.org/lang/ko/

 

게임의 버전을 짜는 것은, 생각보다 중요하게 접근해야 할 일입니다.

아래는 머릿말이며, 자세한 내용은 위 사이트에서 확인하세요!

 

 

---------------------------------------------------------------------------------------------

 

소프트웨어 관리의 세계에는 “의존성 지옥”이라 불리는 성가신 문제가 있다.

시스템 규모가 커질수록, 그리고 더 많은 패키지를 가져다 쓸수록, 언젠가, 이 절망의 늪에 빠진 자신을 발견하기 쉽다.

 

의존성이 높은 시스템에서는, 새 패키지 버전을 배포하는 일이 금방 끔찍해지곤 한다.

의존성 명세를 너무 엄격하게 관리하면, 버전에 갇히게 될 위험이 있다

(의존하는 모든 패키지의 새 버전을 배포하지 않고는 업그레이드할 수 없게 된다).

 

의존성을 너무 느슨하게 관리하면, 버전이 엉켜서 괴롭게 될 것이다

(지나치게 나중 버전까지 호환될 거라 가정한 경우).

버전에 갇히거나 엉켜서 쉽고 안전하게 프로젝트를 계속 진행할 수 없다면 의존성 지옥에 빠진 것이다.

 

이 문제의 해결책으로, 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 제안한다. 

이 규칙들은 기존 오픈 소스/비공개 소스 소프트웨어에 널리 활용되는 규칙을 바탕으로 했으나,

반드시 따르고자 제약을 받지는 않았다.

 

이 시스템이 동작하려면, 먼저 공개(public) API를 선언해야 한다. 문서와 소스 코드 자체로 드러낼 수 있다.

어떤 방식이든 API가 명확해야 한다. 한번 공개 API를 정의하고 나면, 버전 번호를 올리는 방식을 통해 API가 어떻게 바뀌는지 표현한다.

버전을 X.Y.Z (주.부.수) 형식으로 정한다. API에 영향이 없는 버그 수정은 수(修)버전을 올리고, API가 호환되면서 바꾸거나 추가하는 경우에는 부(部)버전을 올리고, API가 호환되지 않는 변경이라면 주(主)버전을 올린다.

 

이 체계를 “유의적 버전”이라고 부르고자 한다. 이 체계를 따르면, 버전 번호와 그 번호를 바꾸는 방법을 통해

특정 버전에서 다음 버전으로 넘어가면서 코드가 어떻게 바뀌는지를 드러낸다.

 

- 머릿말에서 발췌.