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

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

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

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

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

Вся путаница проистекает из различной семантики, которую 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

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

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

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

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

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

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

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

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

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

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

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

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

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

MAJOR.MINOR [.build [.revision]]

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

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

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

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

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

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

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

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

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

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

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

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

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

Редакция может использоваться для исправлений сборок. Допустим, над продуктом работают 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.01.2.1234

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

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