Дата как номер версии программного обеспечения

Разработчики программного обеспечения обычно не используют дату в качестве номера версии, хотя формат ГГГГММДД (или его отклонения) выглядит достаточно надежным для использования. Что-то не так с этой схемой? Или это применимо только к ограниченным «типам» программного обеспечения (например, для собственного производства)?

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

В общем, ваши клиенты не будут сильно беспокоиться о том, какой будет номер версии программного обеспечения, если они знают, что работают с чем-то более новым (то есть Product 2012 новее, чем Product 2010) и знают, что это знают. обновляется, если есть исправления, которые можно развернуть (например, Product 2012, Update 10). Таким образом, с точки зрения брендинга клиента я предпочитаю либо именованные выпуски (например, Windows XP, Windows Vista) с последующим строгим порядковым номером исправлений, которые могут быть установлены пользователями.

Тем не менее, написание программного обеспечения, которое проверяет, что легко для пользователя, имеет тенденцию усложнять процесс написания кода. Поэтому я предпочитаю использовать простую Major.Minorсхему версий хотя бы потому, что вы можете сделать простое сравнение чисел, чтобы проверить, что что-то актуально, как показано ниже:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

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

Однако две вышеупомянутые схемы на самом деле не применимы только к средам, в которых используется непрерывное развертывание (т. Е. Stack Exchange), где я, как правило, предпочитаю какую-то дату, за которой следует номер редакции, который, как представляется, используется на Stack Exchange. места. Причиной этого является то, что версии будут меняться слишком часто в среде непрерывного развертывания, и в один и тот же день может появиться несколько версий кода, что оправдывает номер редакции, а текущая дата так же хороша, как и любая другая еще больше. Теоретически вы можете просто использовать номер редакции для всего, но использование текущей даты позволяет вам отслеживать основные этапы внутри компании, которые могут облегчить обсуждение.

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

«Эта часть функциональности должна появиться в версии 1. Другая часть функциональности должна появиться в версии 2.»

Вы не можете ссылаться на дату в спецификации, так как дата выпуска может быть пропущена.

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

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

Хотя этот подход имеет преимущества, как вы описали, есть определенные недостатки, если вы используете дату в качестве номера версии:

• Версии на основе даты являются плоскими. С v2.1.3 вы можете увидеть номер версии, номер под-версии и номер под-версии. С 20110119 вы можете видеть только когда он был написан. Вы можете сгруппировать свои версии на основе даты по месяцам, но это все равно ничего вам не скажет. У вас может быть несколько медленных месяцев исправления небольших ошибок, а затем две недели интенсивного кодирования, что приведет к серьезной версии. Даты не говорят вам этого, обычные номера версий.

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

Версии часто используются для передачи информации о том, насколько конкретная версия программного обеспечения отличается от предыдущей. Так, например, если вы обновите Acme с 1.0 до 2.0, это будет серьезное обновление, теоретически несущее серьезные изменения.

Обновление с 1.0 до 1.1, с другой стороны, является незначительным обновлением и теоретически содержит незначительные, постепенные изменения и исправления ошибок.

Это было бы трудно представить в формате даты, хотя вы могли бы использовать смесь. Например, v1.0.YYYY.MMDD

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

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

Например, ядро ​​Linux было разветвлено около 2000 года в старую ветку 2.4.x, которая, вероятно, все еще поддерживается сегодня и считается 2.4.199, в то время как новая версия была 2.6 много лет, и 2.6.32 для старых систем, но 3.2 для новейших ядер.

Если у вас есть документация о ваших выпусках, вы удвоите информацию и сообщите людям, что версия 20120109 поступила в 2012 году в 01.09. Миллигенри Но что, если в последний момент обнаруживается ошибка, и выпуск откладывается на неделю, но документация, где упоминается имя, уже готова, может быть напечатана, информация для прессы отсутствует и так далее. Теперь у вас есть расхождение, которое проблематично, если версия 20120109 поступила в 2012/01/13.

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

Ubuntu с его схемой 04/10 имела проблемы в 2006 году, когда версия 6.04 была отложена и стала 6.06. В 3000 году скоро будет следующая проблема! :)

Есть много программных пакетов, которые действительно используют дату как версию. Ubuntu приходит на ум, где их версия YY.MM. И номера сборки для продуктов Microsoft Office также являются кодировкой даты сборки. Джефф Этвуд написал пост в блоге Coding Horror о нумерации версий , включая эту рекомендацию:

По возможности, используйте простые даты вместо номеров версий, особенно в публичных названиях продуктов. И если вам абсолютно необходимо использовать номера версий для внутреннего использования, все равно сделайте их датами: обязательно закодируйте дату сборки где-нибудь в вашем номере версии.

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

Используйте семантическое управление версиями - таким образом, вы получите представление о том, какие изменения вносятся между версиями, без необходимости проверять сам код: http://semver.org/

Использование номеров версий - это способ показать, насколько большие изменения

Например, 2.4.3 может означать, что версия 2 является основным изменением для всей системы. .4 это незначительное обновление. и последняя .3 - это небольшая ошибка в этой версии. Таким образом, легко узнать, сколько изменилось между каждой версией.

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

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

Другими словами, я говорю о ситуациях, в которых нет фактического «номера версии», а в основном своего рода квази-ежедневный дамп репозитория.

Когда я сталкиваюсь с такими вещами, я обычно приветствую выбор, так как для меня более полезно знать, что я использую относительно актуальный скрипт / lib, а не конкретную версию.

Даты в качестве номера версии хороши для маркетинга. Если люди используют «Windows NT 5.0», они могут не осознавать, что она устарела. Но если люди все еще используют «Windows 2000», они сразу узнают, что это 12-летняя ОС, и им будет предложено обновить ее.

Однако это усложняет различие между «основными» и «второстепенными» обновлениями.

Проблема с использованием дат в качестве номеров версий

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

Я пытаюсь сказать, что могу сказать, что Windows 3.1 и Windows 7 находятся далеко друг от друга ... и, возможно, несовместимы. Windows 95 и Windows 2000 не говорят мне ничего, кроме года, в котором продукт был представлен.

Например, с Python я знаю, что версия 2.7.2 эволюционировала от 2.4.6. Если я посмотрю дальше, то увижу, что версия 2.4.6 была выпущена 19 декабря 2008 года; и эта версия 2.7.2 была выпущена 11 июня 2011 года. Из этого я могу составить мнение о стабильности (то есть частоте выпуска) продукта.

Если вместо этого Python использовал даты выпуска, я не могу знать, как эти продукты могут быть связаны. Дальнейшая путаница может привести к тому, что Python 3.1.4 также был выпущен 11 июня 2011 года (так же, как Python 2.7.2).

Короче говоря, я не думаю, что само по себе определение даты является ценным.

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

Но что бы вы ни делали: выберите одну схему именования версий и придерживайтесь ее . Не делайте это как Windows, где они меняют схему с каждым выпуском. И не делайте этого, как Android, где каждый выпуск имеет номер версии API (8), номер версии, предназначенный для маркетинга (2.2), и глупое имя (Froyo).

Дата как версия

Если ваш продукт не продается, то просто использовать дату хорошо и, вероятно, полезно. Если вы продаете его и получаете обновления для клиентов, они хотят купить модель с определенным набором функций. Гораздо проще продать их на апгрейде, если у этой модели есть четкое название, не имеет значения, что это такое, но, например, никто не покупает Ford Car 20 января 2012 года, им нужна модель Kia. То же самое относится и к программному обеспечению. Если указать точное название модели и версию, это означает, что она имеет функции, отличные от старых. Для меня просто свидание не делает этого, оно говорит, что я сделал это тогда, не может иметь новые функции.

Схема, которую мы используем

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

1200_GLD_120120_F0D1

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

Таким образом, мы могли бы иметь последовательность

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Обычно мы обращаемся к основным номерам версий для клиента, т. Е. «12», но клиент получит последнюю золотую версию 12, т. Е. 1200_GLD_120120_F0D1, если только он не нуждается в исправлении.

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

Скажем, последняя версия второй версии 2.3.2, а третья версия 3.0.3. Теперь вы найдете уязвимость, которую абсолютно необходимо исправить, поэтому вы выпускаете 2.3.3 и 3.0.4 в один и тот же день. Вы видите, как дата выхода абсолютно не имеет значения? Возможно, вы прекратили работу над второй версией в 2013 году и с тех пор выпустили только некоторые важные исправления ошибок. Дата не имеет значения по сравнению с номером версии.

Я думаю, что это прекрасно работает. Я использую его для некоторых внутренних программ (yyyy.mm.dd) и для некоторых программ с открытым исходным кодом, которые я выпустил.

Это может работать не во всех случаях.

Технически, он не может использовать дату для номера версии, но может показать номер даты для клиента. Например, macOS 16.7.23 --- это означает, что: 23/7/2016

Я думаю, что технология не проблема, проблема в том, каково это? Если использовать номер даты, который может сделать программное обеспечение живым, живым, точно так же, как человек, у которого день рождения. Каждый год, когда мы растем, то же самое, что и программное обеспечение, продолжает расти.

Номер здания выглядит как машина, машина, ни живой, ни живой.