Подтвердить что ты не робот

С# Эффективный способ управления номером версии

С# 2008 SP1

Мне интересно, как лучше всего обрабатывать номера версий.

Я всегда думал, что обычно всего 3 цифры. (Основные, мелкие и исправления ошибок).

Однако мне остается задаться вопросом, что такое номер сборки и номер версии.

Например, в прошлом я обычно использовал только 3 числа. У меня есть некоторые очень незначительные изменения или исправление ошибок. Я бы увеличил 3-е число (исправления ошибок).

Потому что я новичок в этом. Что обычно делается в профессиональном мире?

Большое спасибо за любой совет,

В моем файле AssemblyInfo у меня есть следующее:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.2.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

// 1.0.2 Added feature for detecting if a sound card is installed.
4b9b3361

ОТВЕТЫ

Ответ 1

Спасибо за все ваши предложения.

Я решил использовать следующее.

Мой проект имеет следующий номер версии: 1.0.2.20. 1. Основные изменения 0.: Незначительные изменения 2.: Исправлены ошибки 20: номер пересмотра Subversion

Итак, я изменил следующее в файле assemblyinfo.c

[assembly: AssemblyVersion("1.0.2.20")]

Любые предложения по этой идее, я был бы рад услышать.

Большое спасибо,

Ответ 2

От MSDN:

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

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

Phil Haack имеет хорошую деконструкцию системы управления версиями .NET, но на практике я не думаю, что его проблемы действительно имеют значение, поскольку в моем опыт системы управления версиями .NET/MS действительно используется только техническими средствами для отладки/поддержки/отслеживания, общественность и управление проектами часто являются датами или созданными на основе маркетинга-версий.

FWIW каждый .NET-проект, над которым я работал, был "X.Y. *", то есть мы хотели бы вручную контролировать, что такое майор и несовершеннолетние, но пусть система контролирует сборку и ревизию.

Ответ 4

Я думаю, что ответ Пола Александра правильный, но я хотел бы добавить следующее примечание к вашему файлу AssemblyInfo:

Если вы используете 1.0.2.*, помните, что последний бит (замененный на *) является случайным числом. Итак, если вы построите 1.0.2. * `этим вечером, и вы построите его завтра утром, вторая версия может имеют более низкий номер версии, чем сборка, которую вы делали ранее.

Ответ 5

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

Подробнее о нашей политике версий сборки.

Ответ 6

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

Идея состоит в том, чтобы идентифицировать случайные релизы, и как-то мне нравится идея. Делайте то, чтобы вы легко могли видеть вещи, которые неправы. Это не говорит о том, что нечетное число обязательно является не случайным выпуском, а только с довольно высокой вероятностью.