Как ранние номера версий работают для новых продуктов?

11

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

Мое исследование подняло эти связанные результаты

но ни один из них не касается нумерации альфа, бета-версий, кандидатов на освобождение и т. д. Каковы соглашения для номеров версий ниже 1.0? Я знаю, что они могут продолжаться в течение некоторого времени; например, PuTTY существует уже не менее десяти лет и все еще находится в бета-версии 0.60.

попса
источник

Ответы:

30

Это действительно зависит от проекта; некоторые проекты даже не выпускают версию 1.0.

Разработчики MAME не намерены выпускать версию 1.0 своей программы-эмулятора. Аргумент в том, что он никогда не будет действительно «закончен», потому что всегда будет больше аркадных игр. За версией 0.99 последовала версия 0.100 (минорная версия 100> 99). Аналогичным образом за Xfire 1.99 последовало 1.100. После 6 лет разработки eMule еще даже не достиг версии 0.50. Управление версиями программного обеспечения в Википедии

Один из популярных методов нумерации версий (который я начал использовать) - это семантическое управление версиями .

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

Некоторые цитаты, чтобы дать вам больше идей о том, как это работает и / или ответить на некоторые ваши вопросы:

Как я знаю, когда выпустить 1.0.0?

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

Разве это не мешает быстрой разработке и быстрой итерации?

Основная версия ноль - все о быстрой разработке. Если вы меняете API каждый день, вы все равно должны быть в версии 0.xx или в отдельной ветке разработки, работающей над следующей основной версией.

Если даже самые незначительные назад несовместимые изменения в общедоступном API требуют значительного увеличения версии, разве я не получу очень быстро версию 42.0.0?

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

Существуют также правила определения версий «альфа», «бета» и т. Д. Проверьте детали на http://semver.org/ .

[Edit] Еще одна интересная схема нумерации версий, которую использует MongoDB :

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

В версии MongoDB 3 числа: ABC

  • А является основной версией. Это будет редко меняться и означать очень большие изменения
  • B номер выпуска. Это будет включать в себя множество изменений, включая функции и вещи, которые могут нарушить обратную совместимость. Четные B будут стабильными ветвями, а нечетные B будут развитием.
  • C - это номер редакции, который будет использоваться для ошибок и проблем безопасности.

Например:

  • 1.0.0: первый выпуск GA
  • 1.0.x: исправление ошибок до 1.0.x - настоятельно рекомендуется обновить, очень небольшой риск
  • 1.1.x: выпуск для разработки. это будет включать в себя новые функции, которые еще не полностью завершены и находятся в стадии разработки. Некоторые вещи могут отличаться от 1.0
  • 1.2.x: второй выпуск GA. это будет кульминацией релиза 1.1.x.
Мишель Тилли
источник
Вау, это ... довольно редактировать. Я бы снова проголосовал за тебя, если бы мог.
Pops
2
Благодаря! ^ _ ^ Я думаю, это редактирование, которое подталкивает меня к 1.0.0? :)
Мишель Тилли
@RossPatterson Upvotes и принимает семантически разные; этот ответ содержит много полезной информации, но я не думаю , что это « ответ» , поэтому прием не чувствует себя хорошо.
Pops
1

Я не думаю, что есть «стандарт» как таковой.

Существует соглашение для Release Candidates, которое обычно называется «[version] RC 1» и т. Д., В зависимости от того, сколько версий вы можете выпустить.

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

Я бы использовал «Альфа» и «Бета», как Release Candidate - для ограниченных по времени версий, чтобы показать, что вы думаете, что близки к выпуску полной версии.

ChrisF
источник
Я думал об этом, но я не могу понять, что представляет собой версия 0. Разница между 0.1 и 0.2 и между 0.3.2 и 0.3.3 одновременно имеет и не имеет смысла для меня в соответствии с моделью "несовершеннолетнего релиза" / "исправления исправления".
Pops
@ Лорд - по общему признанию, это - то, где это действительно падает ...
ChrisF
1

Есть страница Википедии о версии программного обеспечения . Для совместного использования версий до 1.0 хорошо работает соглашение, используемое Apple и другими: major.minor.maintSrev, где S - индикатор стадии для предварительных версий: d = разработка, a = альфа, b = бета, rc = кандидат на выпуск. Таким образом, ваша первая внутренняя версия может быть 1.0.0d1.

Для полностью внутренних ревизий достаточно метки времени.

Xan
источник
0

Каждый разработчик по большей части решает, какой стандарт он собирается использовать. В целом, хотя цифры слева от десятичной точки указывают на большие изменения, которые, вероятно, будут очень заметны для среднего пользователя (т.е. изменения функциональности или интерфейса и т. Д.). В правой части десятичной точки это было бы изменение / модификация / дополнение, которое не сильно изменило бы общую функциональность и дизайн, но действительно изменило что-то в самой программе (то есть, сделало функцию быстрее, все еще делая то же самое или исправленное). проблема безопасности). Затем, если вы добавите дополнительные десятичные точки, цифры справа от них будут указывать на все меньшие и меньшие изменения (т. Е. Мелкие исправления ошибок / проблемы безопасности и тому подобное).

Кеннет
источник
Это было бы хорошим ответом на некоторые из связанных вопросов, которые я перечислил в своем посте, и, на самом деле, довольно похоже на некоторые из существующих ответов на эти вопросы - но на самом деле не рассматривает случай «нулевой версии» Я спрашиваю о.
Pops
Почему не так? Все начинается с 0 в информатике ...
Кеннет
честно говоря, в конце концов, единственный человек / люди, для которых номер версии имеет существенное значение, это разработчик (и). Что касается пользователей, то оно имеет только относительное значение. Таким образом, в конечном итоге разработчики могут в значительной степени и более или менее использовать ту схему, которая им кажется.
Кеннет
0

Как уже говорили другие, не существует точного стандарта. Наша организация использует следующие обозначения:

Выпуск 1.0 ---> 2.0 (В продукт добавлена ​​новая улучшенная функция)

Выпуск 1.0 ---> 1.1 (в продукт добавлена ​​новая / улучшенная функция среднего уровня)

Выпуск 1.0 ---> 1.001 (исправления)

Dal
источник
1
"1.0 ---> 1.001 (Исправления)" Правда? Почему не 1.0.1? Это более обычно. Что произойдет, если у вас будет 100 исправлений ошибок?
Джеймс
@ Джеймс - Это НИКОГДА не случится (Знаменитые последние слова, которые я знаю, лол). Если серьезно, мы никогда не достигали 100 исправлений за один раз, и поэтому номер дополнительного релиза всегда менялся до достижения этого предела (1.1,1.2,1.3 и т. Д.). Если бы мы достигли предела, нам, возможно, пришлось бы увеличить номер дополнительного релиза - он стал бы улучшенной функцией среднего уровня с таким количеством исправлений.
Даль
0

Этап «версия 1.0» очень важен для опытных пользователей компьютеров, поскольку подразумевает, что программа выполнена и работает, как и ожидалось. Что-нибудь в версии "0.something" подразумевает, что сами программисты думают, что программа не выполнена .

Вы можете сохранить номера версий «0.1», «0.2» ... для основных достижений функциональности, а затем установить для них номер сборки, который часто является достаточно точной датой и отметкой времени.


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