내가 본 시맨틱 버전의 모든 예제는 사용중인 3 개의 컴포넌트를 보여줍니다. 마침표는 2 자 이하 여야합니다. 에서 $DAYJOB, 우리는 우리의 릴리스 번호 4 개 구성 요소를 사용 :
5.0.1.2
시맨틱 버전 관리가이를 허용합니까?
그리고 더 높은 수준의 논쟁의 여지가있는 질문으로, 그것은 정말로 중요합니까? 시맨틱 버전 관리를 시행하는 것이 좋은 아이디어라고 생각하기 시작했지만 궁극적으로 PCI와 같은 엔티티가이를 무시합니다.
내 PCI 의견을 명확히해야합니다. 문제는 주요 구성 요소와 부 구성 요소가 변경 될 때 감사와 그 비용에 영향을 미치며 반드시 새로운 기능은 아닙니다. 예를 들어, 지불 관련 기능이 도입되면 PCI의 부 번호가 충돌합니다. 그러나 GUI의 무언가와 관련된 새로운 기능을 추가해도 그렇지 않습니다. 패치 만 변경됩니다. 따라서이 경우 다른 사람이 결정을 내리기 때문에 개발자로서 문제에 대해 아무런 언급도하지 않습니다.
시맨틱 버전 관리는 지침입니다. PCI 는 어떤 방식으로 버전을 관리해야하는지에 대해 어디에 언급 합니까?
내 PCI 의견을 명확히해야합니다. 문제는 주요 구성 요소와 부 구성 요소가 변경 될 때 감사와 그 비용에 영향을 미치며 반드시 새로운 기능은 아닙니다. 예를 들어, 지불 관련 기능이 도입되면 PCI의 부 번호가 충돌합니다. 그러나 GUI의 무언가와 관련된 새로운 기능을 추가해도 그렇지 않습니다. 패치 만 변경됩니다. 따라서이 경우 다른 사람이 결정을 내리기 때문에 개발자로서 문제에 대해 아무런 언급도하지 않습니다.
—
void.pointer
@ void.pointer 왜 네 번째 구성 요소를 사용하는지에 대한 예를 들어 줄 수 있습니까? 기본적으로 내부 비용 및 회계 구조를 우회하기 위해 사용하고 있습니까? 팀이 패치 번호를 부딪치지 않고 새로운 기능을 추적 할 수 있도록 하시겠습니까?
—
enderland
@enderland 기본적으로 그렇습니다.
—
void.pointer
MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. 우리는 기본적으로 PCI (및 회사의 PCI 대주주)가 관여하지 않고 3 차 및 4 차 구성 요소 만 변경할 수 있습니다. 나에게 이것이 약간 생각한 것처럼 느껴지지만, 그들이 버전 번호를 관리하는 방식으로 정당화되었는지는 확실하지 않지만 PCI와 감사 프로세스에 대해서는 달리 말할 수는 없습니다.
우리는 또한 3 개가 아닌 4 개의 그룹을 사용합니다. 왜 그렇습니까? C ++이기 때문에. C ++은 이진 역 호환성과 소스 역 호환성을 가지고 있습니다. 전자는 후자를 의미하지만 관계는 대칭이 아닙니다. 따라서 우리는 바이너리 호환성을 위해 4 번째 그룹 (시스템을 핫 패치 할 수 있음)과 소스 호환성을 위해 3 번째 그룹을 사용합니다 (다시 컴파일 할 필요는 있지만 자체 코드를 수정할 필요는 없습니다). 그리고 당신은 그것이 우리에게 효과적이라는 것을 알고 있습니다!
—
Matthieu M.