build.number가 시맨틱 버전 관리의“남용”인 이유는 무엇입니까?

나는 우리의 수석 건축가 중 하나에 제안 된 빌드 시스템 (Gradle을 / Artifactory / 젠킨스 / 요리사)를 설명했다, 그는 나에게 코멘트를 만들어 내가 그 종류의 체중에에 정말 동의하지만, 경험이 충분가 아닙니다.

이 프로젝트는 다른 팀이 재사용 할 수 있도록 Java 라이브러리 (JAR)를 아티팩트로 빌드합니다. 버전 관리를 위해 다음의 의미 론적 접근 방식을 사용하고 싶습니다.

<major>.<minor>.<patch>

어디 patch, 버그 / 긴급 수정을 나타냅니다 minor이전 버전과 호환 버전을 나타내며, major이 API 및 / 또는 이전 버전과 호환되지 않는 변화 중 하나 대규모 리팩토링을 나타냅니다.

전달이 필요한 한 개발자는 원하는 코드를 작성합니다. 이는 QA / TEST 환경에 대한 빌드를 트리거합니다. 일부 테스트 (일부 자동화, 일부 수동)가 실행되었습니다. 모든 테스트가 통과되면 프로덕션 빌드는 JAR을 사내 저장소에 게시합니다. 이 시점에서 JAR의 버전이 올바르게 지정되어야하며 build.numberCI 도구에서 자동으로 생성하여 제공 한 것을 사용 하여 패치 번호로 사용하는 것이 좋습니다.

따라서 버전 관리는 실제로 다음과 같습니다.

<major>.<minor>.<build.number>

다시 build.numberCI 도구에서 제공됩니다.

아키텍트는 CI 빌드 번호를 사용하는 것이 시맨틱 버전 관리의 "남용"이라고 말하면서 이것을 기각했다.

내 질문은 : 이것이 맞습니까? 그렇다면 왜 그렇습니까? 그렇지 않다면 왜 그렇지 않습니까?

— 헤르 피더
소스

답변:

부 번호와 주 버전이 증가하면 빌드 번호가 0으로 재설정되지 않습니다 . 이는 사양 의 섹션 7과 8을 위반합니다 .

새로운 하위 호환 기능이 공개 API에 도입되면 부 버전 Y (xYz | x> 0)를 늘려야합니다. 공개 API 기능이 더 이상 사용되지 않는 것으로 표시되면 반드시 증가해야합니다. 개인 코드에 실질적으로 새로운 기능이나 개선 사항이 도입되면 증가 할 수 있습니다. 패치 레벨 변경이 포함될 수 있습니다. 부 버전이 증가하면 패치 버전을 0으로 재설정해야합니다.

이전 버전과 호환되지 않는 변경 사항이 공개 API에 도입되면 주 버전 X (Xyz | X> 0)를 늘려야합니다. 사소한 패치 레벨 변경이 포함될 수 있습니다. 주 버전이 증가하면 패치 및 부 버전은 반드시 0으로 재설정되어야합니다.

따라서 버전 번호 (주 버전, 부 버전, 패치)는 수동으로 제공해야합니다. 버전 번호는 변경 기록이나 다른 문서를 보지 않고도 한 곳에서 변경 사항을 사용자에게 알리는 데 사용됩니다.

빌드 번호를 포함하려면 +(섹션 10) 뒤에 추가 할 수 있습니다 .

빌드 메타 데이터는 패치 또는 시험판 버전 바로 뒤에 더하기 부호와 점으로 구분 된 일련의 식별자를 추가하여 표시 할 수 있습니다. 식별자는 ASCII 영숫자와 하이픈 [0-9A-Za-z-] 만 포함해야합니다. 식별자는 비워 둘 수 없습니다. 버전 우선 순위를 결정할 때는 빌드 메타 데이터를 무시해야합니다. 따라서 빌드 메타 데이터에서만 다른 두 가지 버전이 동일한 우선 순위를 갖습니다. 예 : 1.0.0- 알파 +001, 1.0.0 + 20130313144700, 1.0.0- 베타 + exp.sha.5114f85.

— 잔여
소스

빠른 후속 조치 @Residuum (및 답변의 경우 BTW +1) : 버전 번호는 항상 수동으로 파생 되어야 합니까? 그렇지 않은 경우 CI / 빌드 번호 대신 어떤 도구를 사용할 수 있습니까?

— herpylderp

@herpylderp이 아니라 Tom Preston-Werner의 'spec'은 그의 견해 일 뿐이며 다른 회사들도 (일반적으로 서로 매우 유사한) 표준을 가지고 있습니다. 대부분의 경우 자동 생성 된 숫자는 버전의 일부입니다. CI 빌드 번호를 사용하는 것이 합리적입니다.

— gbjbaanb

도구를 사용하여 빌드 번호에서 산술을 수행 할 수 있으면 CI 도구를 계속 사용할 수 있습니다. 메이저 또는 마이너 버전 업그레이드로 릴리스 한 빌드에 상관없이 해당 빌드 번호를 현재 CI 빌드 번호에서 빼는 버전 문자열의 표현식에 연결하십시오. Voila, 실제로 빌드 번호를 재설정하지 않고 새 버전의 빌드 번호를 0으로 재설정했습니다.

— KeithS

필자는 DLL에 [major]. [minor]. [revision]. [SVN-Version]을 사용하고 설치 프로그램에는 [major]. [minor]. [SVN-Version]을 사용합니다. CI 빌드 번호는 CI 환경으로 변경 한 후 (키 인증서 설치, GAC에 공통 라이브러리 추가 등) 실패한 빌드가 정확히 동일한 코드베이스에 대해 다시 실행 된 위치를 표시하기 위해 내부 전용입니다.

— KeithS

@gbjbaanb et al .: 내가 참여한 "의미 적 버전 관리"에 대한 모든 토론에서 semver.org 의 정의 가 주제였습니다. 웹에서 "의미 적 버전 관리"를 검색하면 최소한 첫 페이지에는 semver.org 의 정의에 대한 장단점이 있습니다. 자체 버전 관리 체계를 자유롭게 사용할 수 있지만이 용어가 명확하게 정의되어 있으므로 의미 체계화 관리 체계라고 부르지 마십시오.

— Residuum

한 가지 이유는 패치에 여러 빌드가 필요할 수 있으므로 버전 5.7이 있고 5.7.1로 패치하려고하지만 처음 두 버그 수정이 CI 시스템에 제출 될 때 빌드에 실패하면 다음과 같이됩니다. 첫 패치를 릴리스하기 전에 5.7.3에서!

대답은 Microsoft 시스템 에서처럼 4 자리 숫자를 사용하는 것입니다. 네 번째는 빌드 번호이며 "정보 용"으로 만 사용됩니다. 일반적으로 사람들은 저장소 버전 번호를 저장합니다 (SVN 또는 TFS 등을 사용하는 경우) 바이너리를 빌드하는 데 어떤 정확한 커밋이 사용되었는지 확인할 수 있기 때문에 정말 좋습니다. 그러한 것이 없다면 CI 빌드 번호는 합리적인 근사치입니다 (CI 시스템이 빌드 번호를 기억하고 repo 기록에 묶을 수 있기를 원하지만 CI에 의존하지 않습니다) 시스템 기억-이전 빌드를 삭제할 수 없습니다).

한 가지 주목할 것은 버전 관리를위한 Microsoft 스키마는 빌드 번호에 3 번째 위치를 사용한다는 것입니다. Chrome은 1 개의 숫자 만 사용합니다. 우분투는 날짜를 사용합니다. 모든 숫자를 증분시켜야한다는 점을 제외하고는 사용할 "표준"이 없습니다 .

— bj
소스

보편적으로 사용되거나 적용되는 표준은 없지만, 문제 는 사양이있는 의미 체계 버전 관리 에 관한 것으로 보입니다 .

— Doval

예를 들어, Microsoft의 NuGet 버전 관리 는 깨진 숫자를 사용하여 (빌드 번호에 시험판 스타일 사용), Ruby는 major.minor.teeny.patch를 사용합니다 . 어쨌든 빌드 번호는 semver의 일부가 될 수 있으므로 건축가는 tosh와 이야기하고 있습니다 (물론 3 번째 위치가 아닌 + build 여야 함).

— gbjbaanb

SemVer 2.0 사양은 2013 년이고 1.0 사양은 2012 년부터입니다. 사양이 나타나기 전에 NuGet과 Ruby가 자체 작업을 수행했을 가능성이 있습니다. SemVer 사양이 참신한 것은 아닙니다. 그것은 사람들이 이미하고있는 것을 공식화하기 때문에 우리는 모두 12 가지 변형 대신에 한 가지 방법으로 동의 할 수 있습니다.

— Doval

"버전 5.7이 있고이를 5.7.1로 패치하려고하지만 처음 2 개의 버그 수정이 CI 시스템에 제출 될 때 빌드에 실패하면 첫 번째 패치를 릴리스하기 전에 5.7.3에있게됩니다 ! " 그래, 그럼 뭐? 나는 숫자가 건너 뛰면 안된다는 것을 semver에서 기억하지 않습니다.

— Andy