Я знаю с точки зрения .NET, что сборка с версией 1.13 считается более новой версией, чем версия 1.2, потому что каждый номер в версии оценивается индивидуально. Однако с численной точки зрения 1.13 представл ет собой < чем 1.2.
Проблема сводится к читаемости при публикации обновлений для клиентов. От .0 до .9 все равно, но в .10 вы должны различаться. Итак, вы ограничиваете количество выпусков точек до 9 и затем увеличиваете основную версию, когда вы достигаете 0,9?
Пожалуйста, не предполагайте, что конечный пользователь понимает типичные схемы нумерации версий версий.
Update:
Не думайте об этом как о десятичной номер. Параметр (.) Является разделителем между различные поля. Что каждое поле означает (например):
MajorRelease.MinorRelease.BuildNumber
Абсолютно! Вот что я вижу, когда смотрю номера версий. Но это не то, как ваш средний Джо читает текст "1.13". Я думаю, программисты легко проецируют наше понимание на наших пользователей. Вот почему меня интересуют ответы на опыт с путаницей по номерам. Это может быть не проблема, или, возможно, она просто проигнорирована.
Обновление 2: Ответ на "предоставить документацию" или "объяснить это пользователям": они не работают!:) Если вам нужно объяснить номер версии для пользователя, вы уже сделали его более сложным, чем это должно быть. Хотя основной аудиторией для технологии может быть разработчик во многих компаниях, фактические закупки и управление программным обеспечением обрабатываются секретариатами и канцелярскими сотрудниками, которые вообще не имеют развития или технологии. Если их менеджер спрашивает их: "Есть ли новая версия, доступная с 1.9", и они видят "1.11", они могут не регистрировать ее как новую версию.
Не думайте об этом, как десятичное число. (.) - разделитель между разными полями. Каждое поле означает (обычно):
MajorRelease.MinorRelease.BuildNumber
Каждое число является независимым. Так, например, версия 1.12.127 появляется после версии 1.12.82, потому что, когда вы думаете об этом как о трех отдельных полях...
В realease 1, Minor Release 12... построить 127 появляется после сборки 82.
Это стандартная практика, и любой, кто обращает внимание на "номера" версии, действительно должен знать об этом в любом случае. Единственная причина, по которой может возникнуть какое-либо заблуждение, заключается в том, что ваша версия "number" имеет только одну точку, например. "1.13", и в этом случае его можно было бы путать с десятичным числом (неизвестным читателем), что является неудачным, потому что они представляют собой совершенно разные вещи, хотя и используют одну и ту же нотацию. Используете ли вы номера версий? Если это так, это делает намного более понятным, что версии не являются десятичными знаками, например. "1.13.2". Я бы рекомендовал эту практику в любом случае с дизайнерской точки зрения.
Боковая точка. Если вы хотите программно сравнить версии сборок, вы можете просто использовать класс Version, который перегружает операторы сравнения так что вы можете легко проверить, что более просто, просто оценив versionA > versionB.
Я предпочитаю всегда иметь нулевые номера версий пэдов, чтобы избежать путаницы и позволить им правильно сортировать в приложениях "версия не знаю". В этом случае я бы составил 1,13 > 1,02
Преимущество состоит в том, что он правильно сортируется как в цифровом, так и в алфавитном порядке.
1.13 > 1.2
Если вы думаете, что это может запутать клиента, уклонитесь от проблемы - начните нумерацию с 1.10:)
Например: 3.1, 95, 98, Me, XP, Vista, 7
Просто создайте что-то новое, клиент не беспокоится об этом так сильно, как вы думаете. Объясните новые функции, а не номер версии.
Эта проблема тоже меня беспокоила. Zero-padding для & lsquo; разумно & rsquo; сортировка строк кажется хорошей идеей (я бы хотел, чтобы за ней последовало большее количество исходных tarballs, может быть очень сложно определить самые последние из десятков выпусков в противном случае).
Недавно я заметил, что разработчики говорят "1.13" как "одна точка тринадцать", а не "одна точка одна тройка", что является практикой, которую, я думаю, я уступлю. Это дает понять, что номер версии - это строка чисел, а не десятичная. Возможно, нам следовало бы уладить, скажем, тире или косую черту вместо точки в качестве разделителя, чтобы сделать написанную форму менее двусмысленной.
Если вы относитесь к ним как десятичным, вы, вероятно, в конечном итоге получите номера версий, такие как "1.999999", когда будете приближаться к новой крупной версии! (Я помню, что диалоги BASIC с нумерацией строк имеют аналогичную проблему.) Это также напоминает мне о схемах нумерации для TeX и METAFONT (сходится к pi и e соответственно, что, по моему мнению, является блестящим: это предполагает, что программное обеспечение с четко определенная цель должна сходиться к идеальному состоянию, а не к постоянному расширению).
Я только увеличиваю число версий в зависимости от важности выпуска и его квалификации как крупный/младший выпуск. Наверное, мне не очень-то интересно читать номера версий.
нет. В каждом обновлении программного обеспечения для delopers, которые я видел, 1.13 > 1.2
Однако с численной точки зрения 1.13 является < чем 1.2.
Я так не думаю.
Итак, вы ограничиваете количество выпусков точек до 9 и затем увеличиваете основную версию при достижении 0,9?
нет. Мои числа попадают в десятки. Более крупные проекты идут в сотни, для промежуточных сборок.
Я не рассматриваю номер версии как числовое число, а скорее массив числовых элементов. Поэтому я всегда считал естественным, что 1.13 > 1.2. Я бы не увеличил основную версию только потому, что предыдущий младший был 9, и кто-то мог подумать (хотя я считаю маловероятным), что 1.9 позже, чем 1.10.
Номера версий предназначены только для того, чтобы вы знали, с какой сборкой вы работаете, и чтобы пользователи могли видеть, какую версию они имеют.
Как вы это делаете, это зависит от вас.
Вы могли бы сделать A.B.C или I.II.III или что бы вы ни пожелали.
Я пытаюсь сделать это простым для понимания пользователем. Поскольку мне лично все равно, как это.
У меня есть три уровня. Major.Minor.Build
Строка не является обязательной. В проектах, которые часто обновляются, я добавляю номер версии там, чтобы видеть, где мы сидим.
Числа на майоре и миноре являются целыми числами, поэтому 13 больше, чем 2, но обычно мы никогда не заходим так высоко в модификациях Малой модификации, мы скорее склонны объединять второстепенные сборки и подталкивать их к одному крупному.