Номера версий 1.13> 1.2?

Нумерация версий может сбивать с толку, если нумерация версий выглядит как десятичное число, но (.) на самом деле является разделителем между независимыми полями, которые должны читаться примерно так:

MajorRelease.MinorRelease.BuildNumber

Каждое число не зависит от остальных, поэтому версия 1.12.99 может сопровождаться ] версия 1.12.100 (например). В итоге вы получите:

В выпуске 1, второстепенном выпуске 12 ... сборка 100 идет после сборки 99.

Итак, в вашем примере (v1.13> v1.2): второстепенный выпуск "13" должен был появиться через некоторое время после выпуска "2 ".

Это стандартная практика, и любой, кто обращает внимание на «номера» версий , действительно должен знать об этом . Единственная причина, по которой может быть какое-то заблуждение, заключается в том, что в вашем «номере» версии есть только одна точка, например «1.13», и в этом случае его можно потенциально спутать с десятичным числом (неосведомленным читателем) , что прискорбно, потому что они представляют собой совершенно разные вещи, хотя и используют одну и ту же нотацию. Вы используете номера ревизий? Если это так, то становится более ясно, что версии не являются десятичными, например «1.13.2». Я бы все равно рекомендовал эту практику с точки зрения дизайна.

Дополнительный момент: если вы хотите программно сравнивать версии сборок, вы можете просто использовать класс Version ,

Я предпочитаю всегда обнулять номера версий, чтобы избежать путаницы и позволить им правильно сортировать в приложениях, "не знающих о версии". В этом случае я бы пронумеровал 1,13> 1,02

Преимущество в том, что он правильно сортируется как по цифрам, так и по алфавиту.

Например: 3.1, 95, 98, Me, XP, Vista, 7

Просто придумайте что-нибудь новое, клиент не беспокоится об этом так сильно, как вы думаете. Объясняйте новые функции, а не номер версии.

1.13> 1.2

Если вы думаете, что это может запутать покупателя, избегайте проблемы - начните нумерацию с 1.10 :)

Эта проблема тоже некоторое время беспокоила меня. Нулевое заполнение для «разумной» сортировки строк кажется хорошей идеей (я бы хотел, чтобы за этим последовало больше архивов исходных текстов; В противном случае может быть очень сложно выделить самый последний среди десятков выпусков).

Недавно я заметил, что разработчики говорят «1.13» как «одна точка тринадцать», а не «одна точка тринадцать», что является практикой Думаю усыновлю. Это дает понять, что номер версии - это строка чисел, а не десятичная дробь. Возможно, нам следовало бы использовать, скажем, тире или косой черты вместо точки в качестве разделителя, чтобы сделать письменную форму менее неоднозначной.

Если бы вы действительно рассматривали их как десятичные дроби, вы, вероятно, получили бы номера версий, такие как «1.999999» по мере приближения к новой мажорной версии! (Я помню, что у BASIC-диалектов с нумерацией строк возникла похожая проблема.) Это также напоминает мне схемы нумерации Кнута для TeX и METAFONT (сходящиеся к pi и e соответственно, что я считаю блестящим:

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

нет. Во всех версиях программного обеспечения для делоперов, которые я видел, 1.13> 1.2

Однако с числовой точки зрения 1,13 меньше 1,2.

Я так не думаю.

Итак, ограничиваете ли вы количество точечных выпусков до 9, а затем увеличиваете основную версию, когда достигнете .9?

Нет. Мои числа исчисляются десятками. Более крупные проекты идут на сотни для промежуточных сборок.

Я не считаю номер версии одним числовым числом, а скорее массивом числовых элементов. Поэтому я всегда считал естественным, что 1.13> 1.2. Я бы не стал увеличивать основную версию только потому, что предыдущая второстепенная версия была 9, и кто-то может подумать (хотя я считаю это маловероятным), что версия 1.9 старше 1.10.

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

Как именно вы это делаете, зависит от вас.

Вы можете использовать ABC или I.II.III или что угодно

Я стараюсь сделать это простым для понимания пользователем. Поскольку мне лично все равно, как это.

У меня три уровня. Major.Minor.Build

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

Числа в Major и Minor являются целыми числами, поэтому 13 больше, чем 2, но обычно мы никогда не поднимаемся так высоко в второстепенных ревизиях, мы предпочитаем объединять второстепенные сборки и объединять их в одну основную.