Что именно является номером сборки в MAJOR.MINOR.BUILDNUMBER.REVISION

55

Что я думаю о Build Numbers, так это то, что всякий раз, когда создается новая ночная сборка, генерируется новый BUILDNUMBER и присваивается этой сборке. Так что для моего приложения версии 7.0 ночные сборки будут 7.0.1, 7.0.2 и так далее. Это так? Тогда какая польза от REVISION после номера сборки? Или часть REVISION увеличивается после каждой ночной сборки? Я немного запутался здесь ... мы называем каждую ночную сборку как BUILD ?

Формат упоминается здесь: AssemblyVersion - MSDN

A9S6
источник
Тогда вы можете использовать дату в качестве номера сборки!
2
Сборка: каждая новая сборка системы, Revision: Hotfix или «ревизия» выпущенной сборки, поэтому, почему она изменяет версию сборки; Ваша текущая сборка может быть 2.2.12.0, но выпущенная сборка может быть 2.2.8.0, и когда вам нужно это исправить, вы извлекаете исходный код для 2.2.8, пересматриваете его и собираете 2.2.8.1, спустя 3 месяца 2.2.16.0, но один клиент все еще находится на 2.2.8.1 и сталкивается с другой ошибкой, вы извлекаете код для 2.2.8.1 и исправляете его, чтобы исправить ошибку, и выпускаете его как 2.2.8.2
Джимми Хоффа

Ответы:

57

Я никогда не видел, чтобы это было написано в такой форме. Там, где я работаю, мы используем форму MAJOR.MINOR.REVISION.BUILDNUMBER, где MAJOR является основным выпуском (обычно много новых функций или изменений в пользовательском интерфейсе или базовой ОС), а MINOR является второстепенным выпуском (возможно, некоторыми новыми функциями) в В предыдущем основном выпуске REVISION обычно является исправлением для предыдущего вспомогательного выпуска (без новой функциональности), а значение BUILDNUMBER увеличивается для каждой последней сборки ревизии.

Например, редакция может быть передана в QA (контроль качества), и они возвращаются с проблемой, которая требует изменения. Ошибка будет исправлена ​​и возвращена обратно в QA с тем же номером REVISION, но с увеличенным значением BUILDNUMBER.

tcrosley
источник
+1: Я тоже видел это повсюду. Я видел и любил, как некоторые компании просто используют штамп DateTime для BUILDNUMBER.
Стивен Эверс
4
+1: форма "MAJOR.MINOR.REVISION.BUILDNUMBER" понятна и имеет смысл. Я увидел форму BUILDNUMBER.REVISION на сайте MSDN (ссылка обновлена ​​в вопросе), и она полностью смутила меня.
A9S6
1
Странный. Я ожидаю, что ревизия будет последней, чтобы иметь больше смысла - это число, которое (вероятно) изменится больше всего.
Изката
1
@Izkata, на самом деле номер сборки больше всего меняется, как минимум то, как мы используем его в моем основном контракте прямо сейчас, где используется строгий контроль версий, потому что мы производим медицинские устройства. Обновленная версия указывает, что было исправлено предыдущее программное обеспечение, которое должно быть проверено QA (Quality Assurance). Это совершенно отдельный отдел, который проводит обширное тестирование в течение трех дней (согласно рекомендациям FDA). Если они обнаружат какие-либо проблемы, то могут потребоваться дополнительные изменения кода, требующие новой сборки (перекомпиляции и ссылки), а затем повторного тестирования, но номер редакции останется прежним.
tcrosley
@ tcrosley Полагаю, это неясная терминология. Я думал о ревизиях в управлении версиями.
Изката
19

Вся путаница проистекает из различной семантики, которую MS использует для «номера сборки» и особенно «ревизии». Термины просто означают разные вещи.

Большинство людей (включая меня) используют семантическую схему нумерации версий, при которой вы просто получаете больший номер BUILD всякий раз, когда вам по какой-либо причине необходимо создать новую сборку. Для нас исправление считается еще одним изменением кода, и часть BUILD увеличивается автоматически с каждым запуском CI. Модули с одним и тем же MAJ.MIN.REV считаются взаимозаменяемыми, и BUILD сообщает вам, какой из них является самым последним.

Однако увеличение значения REVISION указывает на новую ветвь постоянного выпуска, поэтому мы размещаем ее перед BUILD. Недостатком этого подхода является то, что мы можем получить следующую последовательность событий:

  • Фиксация 4711: Алиса добавила функцию A
  • CI производит сборку 1.2.3.100
  • Фиксация номер 4712: Боб изменил функцию B
  • Фиксация 4713: Алиса исправила функцию A («исправление»)
  • CI производит сборку 1.2.3.101

major.minor.revision.build

Как видите, исправление - не единственное изменение, содержащееся в следующей сборке, также модификация Боба становится частью этой сборки. Если вы хотите стабилизировать текущую ветку, вы можете столкнуться с проблемами, так как никогда не можете быть уверены, добавил ли Боб кучу ошибок.

MS использует оба термина по-разному. Номер BUILD не увеличивается автоматически, вместо этого его можно рассматривать как разновидность ветки релиза, чтобы заморозить код, используемый для конкретной версии кода. Пересмотр указывает на дополнительные «горячие» изменения, примененные к этой ветви BUILD. Следовательно, последовательность будет следующей:

  • Фиксация 4711: Алиса добавила функцию A в транк / мастер
  • Карл создает ветку сборки 1.2.100
  • CI производит сборку 1.2.100.0
  • Фиксация 4712: Боб изменил функцию B в транке / хозяине
  • Фиксация 4713: Алиса исправила функцию A в 1.2.100ветке
  • CI производит сборку 1.2.100.1

major.minor.build.revision

Термин ПЕРЕСМОТР может относиться к

  • продукт пересмотр (это, как большинство людей используют его)
  • пересмотр конкретной ежедневной сборки (это то, что делает MS)

Основное различие между этими двумя процессами заключается в том, хотите ли вы применять исправления к сборкам CI и, следовательно, в какой момент процесса создается ветвь. Этот аспект становится важным, когда вы хотите иметь возможность выбрать конкретную сборку в любое время после успешного завершения всех тестов и продвигать именно эту версию до следующего официального выпуска вашего продукта.

В нашем случае инструмент CI создает тег репозитория, поэтому у нас всегда есть необходимая информация, готовая к использованию, когда это необходимо. С SVN это становится еще проще, потому что теги и ветви реализованы точно так же - тег - это не что иное, как ветвь, расположенная под ним /tags.

Смотрите также

Из раздела FAQ в стратегии ветвления TFS :

В какой ветке я должен исправить тикет P1 (исправление)?

  • P1 должен быть зафиксирован в ветви, ближайшей к базе кода, работающей в Production. В этом случае P1 должен быть зафиксирован в ветви Prod. Применяя исправление в любой другой ветке и внедряя изменения в рабочую среду, вы рискуете высвободить неполный или непроверенный код из последующих итераций.

  • Теперь вы можете спорить, безопасно ли работать напрямую с веткой Prod, подумайте еще раз, P1, который требует немедленного внимания, не должен быть фундаментальной проблемой в системе. В случае, если это является фундаментальной проблемой, ее следует добавить в Журнал ожидания продукта, так как это может потребовать дальнейшего анализа и обсуждения с клиентом.

Другое хорошее чтение - руководство по ветвлению TFS.

JensG
источник
Это отличный ответ! +1
Lankymart
16

Microsoft описывает назначение каждого компонента номера версии .NET в своей документации MSDN для этого Versionкласса. Вот соответствующая часть:

MAJOR.MINOR [.build [.revision]]

Компоненты используются по соглашению следующим образом:

Major: сборки с одинаковым именем, но разными основными версиями не являются взаимозаменяемыми. Более высокий номер версии может указывать на существенное переписывание продукта, когда нельзя предположить обратную совместимость.

Незначительный: Если имя и номер основной версии на двух сборках совпадают, но номер вспомогательной версии отличается, это указывает на значительное улучшение с целью обеспечения обратной совместимости. Этот более высокий младший номер версии может указывать на точечный выпуск продукта или полностью обратно совместимую новую версию продукта.

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

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

http://msdn.microsoft.com/en-us/library/system.version.aspx

Коул Кэмпбелл
источник
9
Это сбивает с толку, почему никто не знает этот стандарт, каждый ответ здесь утверждает, что сборка идет в конце и не понимает, что пересмотр очень прост; это означает исправление. Вы выпускаете сборку, а затем создаете дальнейшие сборки, но когда вам нужно вернуться и исправить этот выпуск, вы обновляете ревизию, чтобы показать, что конкретная выпущенная сборка была изменена для нового выпуска
Джимми Хоффа
2
+1 за ответ с оправданным номером сборки. Простое увеличение числа довольно бесполезно, если ревизия остается прежней (если у вас нет безумной системы сборки, которая зависит от времени). Используя номер сборки , чтобы сигнализировать , что компилятор, платформы и т.д. является полезным.
Томас Эдинг
1
Buildкак recompilation of the same sourceкажется, важный момент, который упущен. Если это изменение кода (которое не требует полного нового основного / незначительного увеличения), то его Revisionтакже необходимо изменить.
PeterX
@PeterX Как в случае специфичных для сборки изменений при повторном таргетинге?
Самис
4

Есть, по крайней мере, пара разных вещей, которые я мог бы представить, ссылаясь на номер сборки:

  1. Версия контроля версий, которая была выпущена. Например, если была выпущена версия ревизии № 12345, это можно отследить, указав номер сборки, и если это исправление, то здесь могут появиться ревизии, поскольку это не новая функциональность, которая увеличивает основные или вспомогательные версии. и номер сборки нужно запомнить на тот случай, если кто-то захочет запустить эту сборку снова.

  2. Идентификатор сервера непрерывной интеграции. В этом случае CI-сервер может нумеровать каждую сборку, которую он выполняет, и, таким образом, номер сборки - это то, что получает успешная сборка, и часть ревизии в этом сценарии не требуется.

Могут быть и другие, которых я не знаю, но это большие, которые я знаю, когда дело доходит до чисел на основе кода.

JB King
источник
4
+1 за № 1. Мне нравится использовать номер версии контроля версий, потому что это значительно упрощает поиск ошибок, зарегистрированных в этой версии в системе контроля версий.
Мейсон Уилер
@MasonWheeler: отлично работает, если вы находитесь в SVN. Но когда вы попадаете на землю dcvs, она становится короткой. Это будет одна вещь, которую я больше всего скучаю по SVN, я добавлю.
Уайетт Барнетт
3

Номер сборки обычно увеличивается при каждой сборке, поэтому он уникален.

Для простоты некоторые сбрасывают номер сборки всякий раз, когда увеличиваются номера MAJOR или MINOR.

Большинство механизмов непрерывной интеграции позволяют автоматически генерировать уникальные номера сборки.


источник
2

Редакция может использоваться для исправлений сборок. Допустим, над продуктом работают 2 команды.

Команда 1 является основной командой разработчиков и производит ночную сборку со следующей схемой версии 1.0.X.0, где X увеличивается. Сейчас они находятся в версии 1.0.50.0. Team 2 время от времени принимает сборку. Допустим, они берут сборку с прошлой недели, которая является 1.0.43.0, и начинают ее использовать. Команда 1 продвигается к 1.0.51.0, когда команда 2 находит проблему в 1.0.43.0.

Теперь команда 1 возьмет эту сборку (43), исправит проблему и предоставит команде 2 сборку 1.0.43.1. Исправление может также распространяться в основной сборке, поэтому изменение появится в 1.0.52.0.

Надеюсь, это ясно и полезно.

* Редакция полезна, когда не все участники проекта используют одну и ту же сборку, и вам нужно исправлять определенные сборки.

Виктор Хурдугачи
источник
2

Позвольте мне просто сказать, как я вижу и использовать это ....

ProgramName версия major.minor.build.revision

Major: Для меня это текущий проект, над которым я работаю. Номер не изменится, пока я не начну новый проект с тем же именем программы. Это означает, что я буквально буду писать новую программу того же пола (пример: доступ v1 - доступ v-2 - доступ v-3 * - все та же программа, но полностью переписанная).

незначительный: это означает, что я добавляю функциональность в текущий опубликованный проект. Например, может быть, я добавил возможность распечатать квитанцию ​​или добавил возможность импортировать фотографии. В основном дополнительные функциональные возможности, которые я хочу добавить сейчас, а не ждать следующего основного выпуска, чтобы это сделать.

build: Это я использую для обозначения очень небольших изменений в опубликованной версии major.minor. Это может быть изменение макета, цветовой схемы и т. Д.

revision: это я использую, чтобы указать на исправление ошибки в текущем опубликованном файле major.minor.build - бывают случаи, когда я не выполняю текущий проект, и возникает ошибка. Эта ошибка должна быть исправлена ​​и опубликована. Это просто означает, что я исправляю то, что уже опубликовал, для правильной работы. Я также использовал бы это, если я работаю над новой сборкой, новым дополнением или запустил новую основную версию. Опубликованная версия, очевидно, должна быть исправлена, пока мы ожидаем следующего основного, вспомогательного или сборочного выпуска.

Таким образом, готовый или зашедший в тупик проект все еще может быть исправлен и использован до тех пор, пока не будет опубликован следующий выпуск.

Я надеюсь, что это даст кому-то лучшее понимание того, как этот тип управления версиями будет (или должен) работать. Для меня это единственное определение и практика, которая имеет смысл при использовании этого типа управления версиями.

Ричард Риндом
источник
1

Я только видел номер сборки как последний номер в идентификаторе выпуска. Я не уверен, как вы пришли к пересмотру номера сборки. Я полагаю, что если вы изменили некоторые не встроенные ресурсы (значки, сценарии БД и т. Д.), Может быть, но большинство проектов, над которыми я работал в последнее время, также имеют все это под контролем версий, поэтому процесс сборки выбирает их, когда делает установщик / релиз. Мне нравятся номера сборки с метками времени, хотя и не совсем так, как описывает @David (мне нравится major.minor.revision.HHMM). Однако там, где я работаю, мы просто используем порядковый номер, который генерирует наш сервер сборки.

TMN
источник
1

Как и jkohlhepp, мы используем третью часть версии, чтобы показать номер ревизии в SubVersion, и четвертую, чтобы показать номер сборки с нашего сервера непрерывной интеграции (Jenkins для нас). Это дает нам несколько преимуществ - установка номера версии, установленного нашим CI-сервером, исключает ручной шаг, который в противном случае мог бы быть случайно пропущен; легко проверить, что разработчик не сделал дерзкий релиз со своего ПК разработчика (что привело бы к тому, что эти цифры равны нулю); и это позволяет нам связать любую часть программного обеспечения как с кодом, из которого он был сгенерирован, так и с заданием CI, которое его создало, просто взглянув на номер версии, что мы иногда находим очень полезным.

Джон Лоусон
источник
0

Это то, что вы хотите, чтобы это было. Я склонен использовать year.month.day.hhmm для моего major.minor.build.revision. Если я продюсирую больше одной минуты, что-то не так. Вы можете просто использовать простое приращение, или я видел несколько сложных генераторов для них. Что вы хотите, чтобы это было. То, что им нужно сделать, - это сделать так, чтобы вы получили доступ к источнику, используемому для создания этого вывода, и все, что позволяет вам это сделать.

Черный лед
источник
0

Последние две цифры являются общим номером сборки

1.01.2.1234

номер сборки 2.1234, однако большинство людей просто используют 1234, так как 2-я часть меняется не часто.

Лэнс Лайонс
источник
1
ОП спрашивает, что такое номер сборки, а не номер сборки в идентификаторе ревизии.
kiamlaluno
0

Наша команда использует третий номер (ревизию) в качестве номера ревизии из хранилища Subversion. Мы используем четвертый номер (сборка) в качестве номера сборки с нашего сервера непрерывной интеграции TeamCity, который фактически создает сборку. TeamCity создает новый файл AssemblyInfo с правильными # в нем во время процесса сборки.

RationalGeek
источник