언제 커밋에 버전 태그를 지정해서는 안됩니까?

30

컨텍스트 : 최근에 Semantic Versioning 에 대해 알게되었고 실제로 내 프로젝트에 가장 효과적으로 사용하는 방법을 결정하려고합니다.

semver가 버전 변경을 위해 주요 변경, 사소한 변경 및 패치를 고려할 때, 커밋에 업데이트 된 버전으로 태그를 지정해서는 안되는 시점은 언제입니까? 모든 변경 사항이 이러한 범주 중 하나에 맞을 것이므로 모든 변경 사항을 버전 화해야하지만 GitHub에서 다양한 인기있는 프로젝트를 볼 때 이것이 수행되는 방식이 아닌 것 같습니다. 실제로 큰 프로젝트에는 수백 개의 태그 만있는 수만 개의 커밋이 있습니다.

— 보텍스
소스

23

되어 모든이 프로젝트에서 안정적인 테스트, 품질 보증 자료를 마스터 커밋?

— Alex Reinking

1

@AlexReinking 모든 커밋은 테스트되었지만 개인 프로젝트의 일반적인 관행에 익숙해 지려고 노력하고 있으므로 작업 중이므로 "변경, 테스트 이외의 다른 시스템은 없습니다. 스스로 저 지르십시오. "

— VortixDev

또한 태그는 나중에 변경할 수 있습니다. 확고한 확약 식별자는 확약 해시 키입니다.

— Thorbjørn Ravn Andersen

9

마스터에 대한 모든 커밋 ?? 당신은 절대 숙달해서는 안됩니다. 마스터로의 모든 병합은 훨씬 더 잘 들립니다.

— xyious

2

@xyious가 머리에 못을 박았다고 생각합니다. master에 대한 모든 커밋 은 develop의 release merge이어야 하므로 master로 끝나는 모든 커밋에는 버전이 지정 되어야합니다 .

— BJ Myers

71

SemVer는 커밋이 아닌 버전 관리 릴리스 와 관련이 있습니다. 버전 제어 모델이 마스터에 대한 모든 커밋을 릴리스로 요구하는 경우, 예, 변경 정도에 따라 모든 커밋에 태그를 지정해야합니다.

그러나 일반적으로 프로젝트는 마스터에서 가장 안정적인 제품을 개발하고 지원 가능한 릴리스에 태그를 지정합니다. 그렇게 할 때 버전 관리 체계에 따라 태그를 지정할 것인데, 반드시 SemVer 일 필요는 없습니다.

— 알렉스 레인 킹
소스

5

SemVer는 대부분 사용자가 사람이 아닌 다른 코드 비트 인 라이브러리에만 적합합니다. 사용자가 새 버전에 자동으로 적응할 수 있기 때문에 대부분의 사용자 용 앱에는 실제로 "중단"변경 사항이 없습니다.

— Qwertie

5

플래그와 출력 형식이 다르게 작동 할 수 있으므로 명령 행 버전의 사용자 용 앱은 의미 적으로 버전이 지정되어야한다고 주장합니다. 회색 영역의 비트.

— Alex Reinking

5

@Qwertie 사용자 기대치는 소프트웨어 기대보다 덜 엄격하지만 여전히 존재합니다. 나는 그들의 인터페이스 나 기능에 '중단'변경을 고려한 것을 발행 한 많은 소프트웨어를 확실히 사용했다. 메이저 릴리스와 마이너 릴리스의 구성 요소를 결정하는 것이 라이브러리보다 더 주관적이지만 반드시 피해야 할 이유는 아닙니다.

— 철 Gremlin

11

@Qwertie-업그레이드 보류. 아직도 오래된 주요 버전의 Windows 및 Office를 실행하는 사람은 몇 명입니까?

— Alex Reinking

5

@Qwertie 변경 로그 나 문서를주의 깊게 읽어 시스템에서 새로운 기능이나 수정 된 기능을 사용하는 방식을 조정하거나 제거 된 기능에 대한 해결 방법을 찾을 수 있도록 영감을 얻었을 수 있습니다. 같은 경우입니다. 소프트웨어가 변경 되었기 때문에 소프트웨어 사용을 변경해야하므로 변경 사항에 대해 명확하게 알려야합니다.

— 철 Gremlin

11

버전 번호는 릴리스에 할당됩니다. 일반적으로 모든 커밋이 릴리스 인 것은 아닙니다. 여기에는 몇 가지 이유가 있습니다.

첫째, 당신이 모든 커밋을 "테스트"한다고 말하면 테스트 레벨이 있습니다. 한 시스템에서 자동화 된 테스트 스위트를 실행하는 것은 모두 훌륭하지만 복잡한 소프트웨어에서는 모든 문제를 해결하지 못할 것입니다. 일부 문제는 하드웨어 또는 구성에 따라 다를 수 있으며 일부 문제는 테스트하기 어려운 요구 사항보다 사람이 고려해야 할 사항에 대한 것일 수 있습니다.

두 번째로 주 버전 번호를 높이는 것은 드문 일입니다. 기본적으로 소프트웨어에 의존하는 모든 것을 수동으로 검사하여 제거 된 기능에 의존하는지 확인해야합니다.

그 결과 현재 기능을 장기적으로 지원할 준비가 된 경우 알파 / 베타가 아닌 전체 릴리스로 "공용 API"에 기능을 추가해야합니다.

셋째, 널리 사용되는 버전 수를 줄이는 것이 좋습니다. 안정적인 브랜치에서도 모든 수정 프로그램에 대해 릴리스를 작성하는 것보다 여러 수정 프로그램을 함께 수집하고 단일 릴리스를 작성하는 것이 좋습니다.

— 피터 그린
소스

2

분명히 말할 것 같지만, 버전 번호의 목적은 모든 사용자가 실행중인 소프트웨어의 버전을 쉽게 결정할 수 있도록하는 것입니다.

누구나 코드의 특정 반복에 액세스 할 수 있고 고유 식별자를 쉽게 판별 할 수없는 경우 해당 반복에는 고유 버전 번호가 있어야합니다. 나는 이것을 '첫 번째 규칙'으로 본다. 결과적으로, 개별 릴리스는 개별 버전 번호를 분명히 원할 것입니다.

그러나 더 많은 것이 등장합니다.

이를 확인하는 한 가지 방법은 각 커밋마다 버전 번호를 충돌시키는 것이지만 일반적으로 좋은 생각은 아닙니다. 상대적으로 작은 변경 작업을 수행하려면 몇 가지 커밋 / 반복이 필요할 수 있으며 0.0.1-> 0.0.2가 많은 누적 변경 사항으로 인해 0.0.2-> 0.0을 보는 것은 외부 세계와 혼동됩니다. .56 누군가 공란을 커밋하면 한 번에 하나의 파일 만 수정되고 기능은 바뀌지 않습니다.

"풀 릴리스 당 하나의 버전"에서 "각 커밋에 대한 하나의 버전"까지의 거리는 사용자, 다른 사용자 및 차이를 메우기 위해 사용할 시스템에 달려 있습니다.

나는 개인적으로 작은 프로젝트를 수행하는 데 익숙하며 다른 사람들이 사용하는 버전과 이들 각각에 대한 범프 버전이 될 때까지 git 해시를 사용하는 것을 기쁘게 생각합니다 (어떻게 손을 잡을 것으로 기대하는지에 관계없이). 그러나 대기업 및 대규모 프로젝트에서는 의미 버전 번호 이외의 항목이 있지만 릴리스 후보 번호 매기기와 같이 각 커밋보다 정확도가 낮습니다. 이것에는 장점이 있지만 복잡성을 더합니다.

— 아무도
소스

0

마스터로 병합되는 모든 풀 요청은 버전이 지정되어야합니다.

새 버전 (최소한 패치)이 아니어야하는 경우 기능 / 수정 등이 완전하지 않기 때문에 마스터에 병합되어서는 안됩니다.

그러나 팀의 워크 플로에 따라 버전없이 마스터하기 위해 여러 번 커밋 될 수 있습니다. 풀 요청에 스쿼시되지 않는 커밋이 여러 개있는 경우 (내 의견으로는해서는 안 됨) 여전히 커밋 10 개와 새 버전 1 개로 끝날 수 있습니다.

— 악의
소스