Основы нумерации версии? [закрытый]

Кажется, я помню, что в старые времена (я говорю о Commodore) мы использовали синтаксис вроде release.version.revision который может быть дополнен либо исправлением, либо сборкой, где исправление обычно представляет собой букву, прикрепленную непосредственно к ревизии. Таким образом, полное число будет выглядеть примерно так:

2.1.44a.786

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

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

Когда вы это сделаете, вы можете захотеть использовать этот номер в качестве третьего (или четвертого) компонента. Выглядит сбивающим с толку, если какой-то продукт перескакивает с версии 1.12345 на 2.12346, но более распространен переход с 1.4.12345 на 2.0.12345.

О том, с какого числа начать, я просто хочу процитировать Эрика С. Раймонда :

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

Мы используем основные .minor.revision.build, где версия - это версия SVN, а build - это номер сборки, основанный на текущей дате (в формате YYDDD, где YY - это год и DDD номер дня, так что 18001 будет 1 января 2018 г.)

Наличие версии SVN невероятно полезно и спасало нас не раз.

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

То же самое с теми, кто предлагает major-dot-minor-revision. Мой общий подход: основные изменения получают новую основную версию. Мол, если мы добавили важные новые функции. Небольшие изменения, такие как добавление некоторых удобных функций или один новый отчет, претерпевают незначительные изменения. Изменения, исправляющие горячие ошибки, подлежат пересмотру.

Я бы определенно избегал называть вашу первую опубликованную версию "0.l" по простым маркетинговым причинам: числа меньше 1.0 звучат как предварительная версия или бета-версия. Я знал, что люди называют свою первую версию 2.

Я использовал

Major.Minor.Release.Build 1.02.4.15

, а также

Year.Month.Date

2009.12.10

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

Посмотрите здесь . В python setuptools есть очень интересная и понятная спецификация нумерации версий. Я уверен, что вы сможете получить из него очень проницательные подсказки.

Вы можете использовать любую форму нумерации версий по вашему желанию.

Я просто рекомендую использовать что-то разумное. Нумерация Major.Minor.Revision популярна, но любая схема нумерации, которую вы пожелаете, «действительна».

Номера версий не являются конкретной спецификацией при разработке программного обеспечения.

Другими словами, одна группа может использовать 1.0.0.0 , другие могут использовать 1.0. 0 и так далее. Не имеет значения .

Просто выберите то, что вам подходит.

Обычно major.minor.revision - самый простой и понятный способ использования. Например, Visual Studio может автоматически назначать вам номера версий, как и другие инструменты. Поэтому все, что вам нужно обновить, - это основные / второстепенные значения. Номера сборки / ревизии обновляются автоматически.

I've always used (rewrite).(feature added).(bug fix).

But set your own rules and make them public so your users understand them.

Во многих бесплатных программах используется трехбалльная система: XYZ, где

• X - для выпусков, нарушающих совместимость.
• Y - для других выпусков, причем четные числа являются стабильными, а нечетные.
• Z - для исправлений.

Таким образом, версия 0.28.1 является стабильным выпуском с одним исправлением, а 2.9.0 - альфа-выпуском без каких-либо исправлений.

Некоторым людям также нравится разрабатывать свои собственные схемы. Например, Tex, который в каждом выпуске соответствует Pi, с номерами версий: 3, 3.1, 3.14 и т. Д.

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

Если вы хотите, чтобы ваша первая версия была 0.0.0.0.0.0.0.1, это нормально, хотя и немного глупо. . Если вы хотите, чтобы ваша первая версия была 106.3, вы тоже можете это сделать,

Я думаю, что решение зависит от гораздо более подробной информации о характере вашей проблемы.

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

2. Что такое характер расчета? С одной стороны, если характер различия заключается в том, что это, например, разница в росте между двумя людьми, то ведение списка, отсортированного по высоте, позволит вам очень быстро найти похожие объекты. Я предполагаю, что настоящая проблема сложнее, но, следуя этой логике, если разница является суммой нескольких линейных величин, вы можете создать многомерный массив, а затем концептуально представить себе набор подобных объектов, находящихся в n-мерной сфере (например, круг, сфера, гиперсфера и т. д.) с центром вокруг ссылочный объект, и снова найти их напрямую. На самом деле мне приходит в голову, что если вычисления радиуса слишком сложны или занимают слишком много времени, хорошим приближением будет создание n-мерного куба (т.е. квадрат, куб, тессеракт и т. Д.) Вокруг эталонного объекта, получение всех объекты, которые лежат внутри этого куба в качестве «кандидатов», а затем просто выполняют фактические вычисления на кандидатах.

Например, предположим, что «разница» - это сумма абсолютных значений разностей трех атрибутов, скажем a1, а2 и а3. Вы можете создать трехмерный массив и установить значение каждого узла массива для объекта с этими значениями, если таковые имеются. Затем, если вы хотите найти все объекты с разницей менее d от объекта o, вы можете написать:

for (x1=o.a1-d;x1<o.a1+d;++x1)
{
  for (x2=o.a2-d;x1<o.a2+d;++x2)
  {
    for (x3=o.a3-d;x1<o.a3+d;++x3)
    {
      if (array[x1][x2][x3]!=null
        && (abs(x1-o.a1)+abs(x2-o.a2)+abs(x3-o.a3)<=d)
        {
          ... found a match ...
        }
    }
  }
}

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

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

как насчет программного обеспечения, которое не распространяется среди общественности, как исходный код веб-почты? как вы думаете, номер сборки или исправления по-прежнему важен в этом случае?