[version] 버전 번호는 어떻게합니까?

복잡한 엔터프라이즈 플랫폼 수준 종속성 관리 및 릴리스 버전 관리에 대한 경험을 바탕으로 Semi-Semantic Versioning 이라고하는 접근 방식을 추천합니다 .

기본적으로 Semantic Versioning 2.0을 기반으로 하지만 엄격하지는 않습니다.

반 의미 버전 세그먼트 :

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

기본 릴리스 세그먼트 형식 :

마케팅, 메이저, 마이너 패치

각 세그먼트는 영숫자를 허용해야하지만 논리적 증분 변경에는 순수한 숫자가 권장됩니다.

SemVer와 마찬가지로 역 호환성 계층을 나타 내기 위해 Major, Minor 및 Patch 구성 요소 를 권장하지만 Marketing 구성 요소 앞에 추가하는 것이 좋습니다 . 이를 통해 제품 소유자, 기능 epics / 그룹 및 비즈니스 문제가 기술 호환성 문제와 무관하게 주요 구성 요소에 부딪 칠 수 있습니다.

다른 답변과 달리 기본 세그먼트에 빌드 번호를 추가하지 않는 것이 좋습니다. 대신 ‘+’뒤에 출시 후 세그먼트를 추가하십시오 (예 : 1.1.0.0 + build.42). SemVer는이 빌드 메타 데이터를 호출하지만 Post-Release Segment가 더 명확하다고 생각합니다. 이 세그먼트는 기본 릴리스 세그먼트 의 호환성 정보와 관련이없는 것으로 접미사 데이터를 선언하는 데 유용합니다.. 그런 다음 지속적인 통합 빌드에 각 1 차 릴리스 후에 재설정되는 증분 빌드 번호가 추가 된 이전 릴리스 번호를 부여 할 수 있습니다 (예 : 1.1.0.0-> 1.1.0.0 + build.1-> 1.1.0.0 + build.2-> 1.1.0.1). 일부 사람들은 코드 저장소에 쉽게 연결할 수 있도록 svn 개정 번호를 여기에 넣거나 git commit sha를 선호합니다. 또 다른 옵션은 핫픽스 및 패치에 릴리스 후 세그먼트를 사용하는 것입니다. 새 릴리스 구성 요소를 추가하는 것이 좋습니다. 버전이 효과적으로 왼쪽 정렬 및 정렬되므로 패치 구성 요소가 증가하면 항상 제거 될 수 있습니다.

릴리스와 릴리스 후 세그먼트뿐만 아니라, 사람들은 종종 사용할 시험판 세그먼트를 알파, 베타 및 릴리스 후보와 같은 거의 안정 사전 릴리스를 나타냅니다. 이것에 대한 SemVer 접근 방식은 잘 작동하지만 영숫자 분류기 (예 : 1.2.0.0 + alpha.2 또는 1.2.0.0 + RC.2)에서 숫자 구성 요소를 분리하는 것이 좋습니다. 일반적으로 릴리스 후 세그먼트를 추가하는 것과 동시에 릴리스 세그먼트를 충돌 한 다음 다음에 주 릴리스 세그먼트를 충돌 할 때 시험판 세그먼트를 삭제합니다 (예 : 1.0.1.2-> 1.2.0.0-RC.1- > 1.2.0.0). 시험판 세그먼트가 추가되어 릴리스 버전이 출시됨을 나타내며, 일반적으로 더 많은 커밋에 따라 분 단위로 변경되지 않는보다 심도있는 테스트 및 공유를위한 고정 된 기능 세트 만 나타납니다.

거의 모든 유스 케이스를 다루는 방식 으로이 모든 의미를 의미 적으로 정의하는 것의 장점은 표준 방식으로 구문 분석, 정렬, 비교 및 ​​증가 할 수 있다는 것입니다. 이는 각각 독립적 인 버전이있는 여러 구성 요소 (마이크로 서비스 등)가 자체적으로 관리되는 종속성이있는 복잡한 응용 프로그램에 CI 시스템을 사용할 때 특히 중요합니다.

당신이 관심이 있다면, 나는 루비로 세미 시맨틱 파서를 썼다 . 이 패턴 만 사용하는 것이 아니라 그 패턴을 사용한 다른 앱을 관리 할 수 ​​있어야했습니다.

답변