.NET의 System.Version이 Major.Minor.Build.Revision으로 정의 된 이유는 무엇입니까?

.NET의 System.Version이 Major.Minor.Build.Revision으로 정의 된 이유는 무엇입니까?

---

.NET의 System.Version이 Major.Minor.Build.Revision으로 정의 된 이유는 무엇입니까? 거의 모든 사람 (나를 포함하여)은 개정이 3 위에 속하고 "빌드"라고 부르고 싶은 것이 마지막에 속한다는 데 동의하는 것 같습니다.

마이크로 소프트는 심지어 3.5.3858.2와 같이 이런 방식으로 숫자를 사용합니까, 아니면 이름 자체가 거꾸로되어 있습니까? 예를 들어 Major.Minor.Build.Revision 순서로 고유 한 Version 클래스를 작성하려는 경우 System.Version으로 변환 할 때 마지막 두 구성 요소를 교체하는 것이 적절할까요? 아니면 무시하고 이름 만 사용하는 것이 적절할까요? 거꾸로?

---

대부분의 사람들이 "개정"으로 간주하는 것과 Microsoft 가하는 일이 혼란 스러울 것 같습니다.

• 빌드 : 빌드 번호의 차이는 동일한 소스의 재 컴파일을 나타냅니다. 이것은 프로세서, 플랫폼 또는 컴파일러 변경으로 인해 적절합니다.

• 개정 : 동일한 이름, 주 및 부 버전 번호를 사용하지만 다른 개정은 완전히 상호 교환 할 수있는 어셈블리입니다. 이것은 이전에 출시 된 어셈블리의 보안 구멍을 수정하는 데 적합합니다.

보안 수정 각도는 아마도 그들에게 훨씬 더 일반적 일 것인데, "가장 사소한"변화처럼 마지막 위치에 있어야 할 적절한 이유 인 것 같습니다.

---

나는 내가 파티에 조금 늦게 오는 것을 알고있다. 그러나 나는 왜 빌드와 수정의 순서가 "잘못되었는지"에 대해 나의 2 펜스를 나누고 싶었다. 그것은 순전히 그들이에있어이지 않는다 잘못된 순서하지만, 자신들이하지 않은 것을 어떤 순서.

어셈블리 버전은 Major.Minor입니다. 앞서 언급 한 링크 에서 Microsoft는 "빌드 또는 개정 번호 만 다른 어셈블리의 후속 버전은 이전 버전 의 핫픽스 업데이트로 간주됩니다 ."라고 말합니다. [내 강조점]

빌드 같은 소스의 재 컴파일을 나타냅니다. 개정 코드 변화를 나타내지 만, 동일 [는 Major.Minor] 버전의 다른 버전과 완전히 교환 할 하나. 그러나 둘 다 다른 것보다 우선합니다.

따라서 요약하면 다음과 같이 생각하지 마십시오.

+ Major
|
+-+ Minor
  |
  +-+ Build
    |
    +-+ Revision

그러나 대신 :

+ Major
|
+-+ Minor
  |
  +-+ Build
  |
  +-+ Revision

---

마이크로 소프트는 3.5.3858.2와 같이 이러한 우연한 방식으로 숫자를 사용합니까?

예를 들어를 지정하여 기본값으로 설정 [assembly: AssemblyVersion("1.1.*")]하면 세 번째 숫자가 매일 증가하고 네 번째 숫자는 자정 이후 초 수를 2로 나눈 값입니다 (하루에 빌드가 두 개 이상인 경우 명확하게하기 위해).

거의 모든 사람 (나를 포함하여)은 개정이 3 위에 속하고 "빌드"라고 부르고 싶은 것이 마지막에 속한다는 데 동의하는 것 같습니다.

마이크로 소프트는 "일"의 동의어로 "빌드"를 사용하고있는 것 같다. 아마도 그것은 "일일 빌드"라는 개념과 관련이있을 것이다. 따라서 "수정"은 (일일) 빌드의 또 다른 버전입니다.

---

늦은 답변이지만 다른 답변은 조금 확장 될 수 있다고 생각합니다.

"빌드"및 "수정"이라는 용어는 Microsoft 용어 일뿐입니다. System.Version 클래스는 사용자가 할당하는 방식을 전혀 신경 쓰지 않습니다.

자신의 용어와 일치하도록 부품의 순서를 바꾸는 것에 관해서는 기본적으로 단어를 완전히 무시하고 대신 System.Version이 실제로 정의 하는 것을 고려해야한다고 말하고 싶습니다 .

• 구문 분석하고 생성 할 수있는 문자열 형식 :

  major.minor[.build[.revision]]
  

  즉, xyzw 형식의 버전을 소유하는 데 익숙하다면 다음과 같이 Version 클래스를 인스턴스화해야합니다.

  new Version(x, y, z, w)
  

  다른 매개 변수 순서는 Parse () 및 ToString ()이 수행하는 작업과 일치하지 않습니다. z와 w를 전환하면 ToString ()은 xywz를 출력하므로 xyzw를 예상하면 모든 사람에게 혼란 스럽습니다.

• 버전 비교 및 정렬 순서 우리의 대부분이 기대하는 것처럼 버전, 주요, 다음 미성년자, 다음, 다음, 구축 개정에 의해 처음으로 분류되어있다. 즉, 1.2.5는 1.2.3.7보다 이후입니다.

  따라서 버전 문자열의 스타일을 1.2.6.4로 지정하고 1.2.5.8보다 새로운 것으로 간주하려면 Version 생성자에서 부품 순서를 전환하지 마십시오.

요컨대-major / minor / build / revision이라는 단어는 변경 사항의 양을 고려하여 어느 숫자를 늘려야하는지에 대한 단서를 제공 할 수 있지만 용어는 클래스가 실제로 사용되는 방식에 거의 영향을 미치지 않습니다. 서식과 정렬이 중요합니다.

참고 URL : https://stackoverflow.com/questions/3098167/why-is-system-version-in-net-defined-as-major-minor-build-revision