일부 프로젝트는 새로운 개발을 시작하기 전에 버전이 충돌하는 반면, 다른 프로젝트는 릴리스에 태그를 지정할 때 버전이 충돌합니다.
어떤 접근법이 더 낫습니까?
새로운 단계가 시작될 때 버전 번호가 변경되지 않은 경우 개발자는 해당 버전을 변경하지 않고 프로그램을 릴리스하는 것을 잊을 수 있습니다.
태그 지정 릴리스 전에 버전 번호가 변경된 경우 버전 번호 (tag 및 Makefile / AssemblyInfo.cs)가 2와 일치하지 않습니다.
git describe 현재 개정판이 v1.2.3.4 이후 인 경우 v1.2.3.4-15-g1234567을 제공하지만 파일을 이미 v1.2.3.5로 변경 한 경우
답변:
버전 번호의 주된 이유는 버그가 발견 될 때 오류가 실제로 발생한 소스 코드의 실제 버전을 사용하여 디버그 할 수 있도록하기위한 것입니다 (따라서 버그의 실제 원인을 발견 함).
제작자가이 목표를 달성 할 수 있도록 충분한 정보를 개발자에게 전달할 수있는 한 사용하는 버전 관리 체계는 중요하지 않습니다.
버전 관리의 다른 이유는 마케팅 및 도움 (때로는 합법적) 팀을위한 것입니다.
이 팀은 버전 관리를 위해 고유 한 우선 순위를 갖습니다.
모든 경우에 사용 된 체계는 중요하지 않습니다. 일관된 한 (또는 의미의 변화에 대한 매우 상세한 문서를 쉽게 구할 수있는 한).
.NET 어셈블리와 같이 4 세그먼트 버전 번호를 사용할 때 버전 제어 태그를 사용하여 처음 세 세그먼트를 설정하는 것을 선호하며 네 번째 세그먼트는 해당 태그 이후의 커밋 수입니다.
예를 들어, 버전은 "v1.2.3"태그가 지정됩니다. 경우 git-describe반환 "v1.2.3-4 - g1a2b3c4는"다음 내장 때 조립 1.2.3.4로 버전 가져옵니다.
나중에 해당 버전에 태그를 적용하면 git-describe버전 1.2.4.0을 나타내는 "v1.2.4"가 대신 반환됩니다. 다음 커밋은 1.2.4.1입니다.
이 시스템에서 얻을 수있는 이점은 다음과 같습니다.