Что использовать в качестве начальной версии? [закрыто]

122

Обычно я начинаю свои проекты с версии 1.0.0. Как только у меня есть что-то вместе, я выпускаю его как 1.0.0 и перехожу к 1.1.0.

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

Что бы вы посоветовали сделать? Начать с 1.0.0 или 0.1.0?

Последний номер предназначен только для исправлений ошибок. Вы можете думать о моем 1.0.0 как о 1.0 и о 0.1.0 как о 0.1, что вам проще.

Noarth
источник
1
Я только что узнал о «семантическом управлении версиями» ( semver.org ), это в основном то, чем я хочу заниматься. Однако я не создаю API, а говорю об API, поэтому совет 1.0.0 на самом деле не применим.
Ноарт,
Похоже на: stackoverflow.com/questions/1795920/…
Фиона - myaccessible.website

Ответы:

-24

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

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

Если это ваш призыв, делайте то, что лучше всего подходит для вас. У меня были проблемы с версиями до 1.0, поэтому я начну с них.

в промежутке
источник
1
Вы действительно ничего не объясняете в своем ответе. Вы не упоминаете, какие проблемы у вас были, поэтому мы можем обсудить это. Вы не объясняете, когда и почему версии управляются заказчиком, что в любом случае не относится к OP. И вы не объясняете, как и почему управление версиями управляется настройкой. Что вы вообще имеете в виду, чтобы дать ответ? Четко сформулированный ответ должен включать «за» и «за» каждого решения, вы включили лишь расплывчатые рассуждения :).
Eksapsy
225

Стандарт семантического управления версиями 2.0.0 гласит:

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

Можно сразу перейти с 0.3.0 на 1.0.0. Также вполне нормально быть на уровне 0,23,0. Запускать с 0.4.0 несколько не рекомендуется, так как это предполагает, что уже были опубликованы предыдущие версии.

Кроме того, обратите внимание, что 0.y.zэто отложено для быстрой итерации, чтобы начальная разработка (и, следовательно, множество критических изменений) не оставила вас в такой глупой ситуации, как 142.6.0. Вместо того, чтобы менять основную версию, увеличивайте второстепенную версию при каждом критическом изменении, пока вы не выпустите 1.0.0:

Основная нулевая версия (0.yz) предназначена для начальной разработки. Все может измениться в любой момент. Публичный API не следует считать стабильным.

Барди Харбороу
источник
Это ДОЛЖЕН быть принятый ответ. Никогда не видел ответа с 16 отрицательными голосами в качестве принятого ответа
Надер Ганбари,
Есть ловушка, если вы используете npm. Если вы начнете с 0, знак вставки «^» в package.json будет вести себя иначе. docs.npmjs.com/misc/semver#caret-ranges-123-025-004 Вы можете использовать 0.x вместо ^ 0. в пакете json для этого сценария. Следовательно, 1.x немного проще запустить и использовать.
Сэм
9

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

Великие программисты фактически использовали систему нумерации версий в качестве местных шуток. Примеры (Википедия):

Начиная с версии 3, TeX использует идиосинкразическую систему нумерации версий, где обновления указываются добавлением дополнительной цифры в конце десятичной дроби, так что номер версии асимптотически приближается к π. Это отражает тот факт, что TeX сейчас очень стабилен, и ожидаются лишь незначительные обновления. Текущая версия TeX - 3.1415926; последний раз обновлялся в марте 2008 г.

Для МЕТАФОНТ:

Metafont имеет систему управления версиями, аналогичную TeX, где число асимптотически приближается к e с каждой ревизией.

Наконец, не совсем номер версии, но не менее интересный: первичное публичное размещение (IPO) Google было подано в SEC для сбора 2 718 281 828 долларов (обратите внимание, что e ~ 2,718 281 828).

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

Escualo
источник
6

Думаю, здесь играют роль разные факторы. Необходимо учитывать психологическое / маркетинговое влияние номера версии (номер версии часто увеличивается => больше $$$, люди не хотят покупать бета-версию 0.99 и т. Д.). Номера версий «логики» могут помочь при работе в большой команде.

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

Александр С.
источник
1

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

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

Тристан
источник
3
Это как-то подразумевает, что вы можете дойти только до версии 0.9.0, но я знаю много проектов, которые продолжаются, например, 0.25.0.
Ноарт
Я обычно использую последний набор цифр для незначительных инкрементных изменений, а также для исправления ошибок и сохраняю средний набор цифр для довольно серьезных изменений, чтобы никогда не приходилось переходить к двузначным цифрам для средних чисел
Тристан,
1

При выборе номеров версий для npmпакета имейте в package.json виду, что зависимости, перечисленные в диапазонах semver , не будут работать ниже v1.0.0. То есть,

"dependencies": {
    "my-package": "^0.5"
}

эквивалентно

"dependencies": {
    "my-package": "0.5"
}

Если вы хотите иметь возможность использовать диапазоны semver или позволить другим людям использовать их, вы можете начать с 1.0.0.

генри
источник
Интересный. У вас есть дополнительная информация о том, почему (или где) диапазоны Семвера не работают ниже 1.0.0? Поскольку 0.0.xв реестре npm используется довольно много пакетов .
Реми
Я не знаю, почему люди из npm приняли это решение, или где в системе npm оно принято / что нужно изменить для поддержки диапазонов semver для версий меньше 1. Мне было бы интересно узнать!
Генри
3
Они приняли такое решение, потому что ^означает «совместимый с версией» . Подробнее здесь . В semver, 0.y.zпредназначена для начального развития , и любые изменения в yили zмогут быть обратно несовместимы. В вашем примере, ^0.5 := 0.5 := 0.5.xзначит, это диапазон. Если диапазон каретки не работает для вас в этом 0.y.zдиапазоне, вы можете использовать диапазоны компаратора, дефиса, x и тильды в дополнение к диапазонам каретки.
dosentmatter
0

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

Если вас беспокоит, что версия 0.6.5 содержит неполное кольцо, вы можете продавать ее под версией 1.0. Номер вашей маркетинговой версии не обязательно должен совпадать с вашим внутренним номером версии. Например, номер версии Windows 7 - 6.1.

Лично я предпочитаю начинать с 0.1.0 и идти оттуда.

Майкл Венейбл
источник
0

Зависит от проекта. Для простых инструментов командной строки я обычно начинаю с 0,9 [.0], поскольку я рассматриваю их выпуск или упаковку только тогда, когда они близки к завершению (или готовы к бета-тестированию, в любом случае). Более сложные проекты начинаются примерно с 0,1 [.0] и некоторые даже не видят 1.0. Я считаю 1.0 выпускной версией (или, по крайней мере, бета-версией или кандидатом на локальную проверку) и планирую соответственно.

Что касается командных проектов, то решает тот, кто ставит первый тег версии :).

AIB
источник
0

0.1.0 - это то, с чего я начинаю, и продолжаю двигаться дальше. Это то, что я адаптировал для Xploration By Adrian, хотя в ранние годы я был очень спорадическим и использовал 1.0.0, 0.0.1 и некоторые другие. Но я рекомендую начинать с 0.1.0 и дальше.

Per Semver, зарезервируйте a и c в abc для A. Вы первый официальный выпуск и C. Исправления ошибок и патчи. Это связано с тем, что основная версия обычно ломает старый код. А патчи просто исправляют ошибки. Это все личные предпочтения, 0.99.0 не означает, что вам нужно переходить на 1.0.0 и т. Д. Я видел некоторые, которые доходили до 0.218.42.

TheGrimSilence
источник
-1

Номера версий должны иметь значение для вас, как правильно прокомментировала Арриета ранее.

Может быть, следуя чему-то вроде: Первый # - мэрский выпуск, Второй # - тот же мэрский выпуск с некоторыми добавленными функциями и Третий # - тот же мэрский выпуск, с теми же функциями, но с исправленными ошибками или небольшими (но достаточно значительными) изменениями.

1.3.2 => 1-й выпуск, с дополнительными функциями и исправленными ошибками.

Однако для конечных пользователей некоторые привыкли к большим цифрам для финальных выпусков.

Например: Corel 8 для 8.0.0, 8.0.1, 8.2.2 и т. Д. Corel 9 для 9.0.0 и т. Д.

И в основном это больше о маркетинговых стратегиях, например: Corel X5 вместо Corel 15.0.2.

Я бы сказал, что это зависит от того, номер версии для вас или для клиента.

оборота Икарин
источник
-4

начните с 0.0.0 и двигайтесь дальше.

всухую
источник
4
Означает ли это, что вы действительно сделаете релиз 0.0.0? Я начинаю с первого номера, который собираюсь выпустить.
Ноарт
-10

Начните с 1.1.1 и двигайтесь дальше.

Знак высокой эффективности
источник