Почему System.Version в .NET определяется как Major.Minor.Build.Revision?

Question

Почему System.Version в .NET определяется как Major.Minor.Build.Revision? Кажется, почти все (включая меня) согласны с тем, что ревизия принадлежит третьему месту, а «сборка» или как вы хотите ее назвать - последняя.

Использует ли Microsoft даже числа таким случайным образом, например, 3.5.3858.2, или сами имена только задом наперед? Например, если вы хотите написать свой собственный класс Version с порядком Major.Minor.Build.Revision, было бы уместно поменять местами последние два компонента при преобразовании в System.Version или вы игнорируете его и просто притворяетесь, что имена назад?

Answer 1

Я думаю, что путаница возникает из-за того, что большинство считает «пересмотром», и , что делает Microsoft :

• Сборка: Разница в номере сборки представляет собой перекомпиляцию одного и того же источника. Это будет целесообразно из-за изменений процессора, платформы или компилятора.

• Редакция: Сборки с одинаковыми именами, номерами старших и младших версий, но с разными ревизиями, должны быть полностью взаимозаменяемыми. Это было бы целесообразно, чтобы исправить дыру в безопасности в ранее выпущенной сборке.

Угол исправления безопасности, вероятно, гораздо более распространенный для них, кажется достойной причиной, чтобы он занял последнее место, как «самое незначительное» изменение.

Answer 2

Я понимаю, что я прихожу на вечеринку немного поздно, но я хотел бы поделиться своим мнением о том, почему порядок сборки и пересмотра «неправильный».Дело не в том, что они в неправильном порядке, а в том, что они не в любом порядке.

Версия сборки, когда она появляетсядо этого, майор. минор.В упомянутой выше ссылке Microsoft говорит: «Последующие версии сборки, отличающиеся только номерами сборки или редакции, считаются обновлениями исправлений предыдущей версии ».[Мой акцент]

Build представляет перекомпиляцию того же источника. Revision представляет собой изменение кода, которое полностью взаимозаменяемо с другими ревизиями той же версии [Major.Minor].Но ни один из них не имеет приоритета над другим.

Итак, в общем, не думайте об этом как:

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

Но вместо этого:

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

Answer 3

Использует ли Microsoft даже числа таким случайным образом, например, 3.5.3858.2

Если вы оставите значение по умолчанию, например, указав [assembly: AssemblyVersion("1.1.*")], затем третье число увеличивается каждый день, а четвертое число - это количество секунд с полуночи, деленное на два (для устранения неоднозначности, если за один день выполняется более одной сборки).

Почти все (включая меня), похоже, согласны с тем, что ревизия принадлежит третьему месту, а "build" или как вы хотите назвать, принадлежит последнему.

Microsoft, похоже, использует "build" как синоним "day": возможно, это связано с идеей "ежедневных сборок"; и тогда «ревизия» является другой версией (ежедневной) сборки.

Answer 4

Поздний ответ, но я чувствую, что другие ответы могут быть немного расширены.

Термины «сборка» и «ревизия» - это просто терминология Microsoft.Класс System.Version никоим образом не заботится о том, как вы их назначаете.

Что касается переключения порядка частей в соответствии с вашей собственной терминологией, я бы сказал, что вы должны полностью игнорировать слова и вместо этого рассмотреть, чтоSystem.Version действительно определяет:

• Формат строки, который он может анализировать и генерировать:

  major.minor[.build[.revision]]
  

  Это означает, что если вы используетечтобы ваша собственная версия была отформатирована как xyzw, вам следует создать экземпляр класса Version следующим образом:

  new Version(x, y, z, w)
  

  Любой другой порядок параметров не будет соответствовать тому, что будут делать Parse () и ToString ().Если вы переключите z и w, то ToString () выведет xywz, что может сбить с толку всех, если вы ожидаете xyzw

• A сравнения версий и порядка сортировки , в результате чеговерсии сортируются сначала по основным, затем по второстепенным, затем по сборке, а затем по редакции, как и следовало ожидать большинству из нас.То есть 1.2.5 более поздняя, ​​чем 1.2.3.7.

  Так что, если вы стилизуете строку версии как 1.2.6.4 и хотите, чтобы она считалась более новой, чем 1.2.5.8, не переключайте порядокчасти в конструкторе Version.

Короче говоря, в то время как слова major / minor / build / revision могут дать представление о том, какое число следует увеличить с учетом количества изменений, терминологияимеют очень небольшое влияние на то, как на самом деле используется класс.Форматирование и сортировка - вот что важно.