Как я могу различать бета-версии и обычные версии?
Я обычно согласен с тем, что основные версии программы должны быть 1.0, 2.0,... и значительными обновлениями должны быть: 1.1, 1.2,... и что исправления ошибок должны быть в третий уровень: 1.0.1, 1.0.2,... 1.0.156 (если вас преследовали многие выпуски исправлений ошибок между версиями).
Но теперь я хочу выпустить свою первую бета-версию, которая станет одной из серии бета-версий, ведущих к выпуску версии 1.0.
В частности, мне не имеет смысла указывать, что мои бета-версии больше числа, которое я разрабатываю, например, 1.0.1 до 1.0.15 (если у меня 15 бета-версий), а затем следуйте за ним с помощью 1.0.
Но использование чисел меньше 1.0 кажется неудобным, например. 0.9.1... 0.9.15 и вызовет путаницу, если я начну использовать 1.9.1... 1.9.15 в качестве бета-версии для версии 2.0.
Связанный:
Как сделать номера версий?
Просто для информации, после вашей помощи и отличных ссылок с дополнительной информацией, это то, что я решил.
Я собираюсь 0,7, 0,8, 0,9, 0,91... до 0,98 для моих альфа-версий.
Я знаю, что могу сделать 1.0 beta 1, что является "стандартным" способом. Но, принимая во внимание все, я собираюсь пойти с: 0.99 beta 1, 0.99 beta 2... прежде чем я доберусь до версии 1.0.
Если я сделаю предварительный выпуск моей версии 2.0, я, вероятно, последую за шаблоном и назову его 1.99 beta 1, 1.99 beta 2 и т.д.
Надеюсь, этот вопрос и ответы помогут вам решить вашу схему.
Ответы
Ответ 1
Я думаю, вы должны отделить свою версию от статуса релиза.
Бета-версия должна всегда иметь "бета-версию" после версии. Пользователям не нужно перепроектировать схему нумерации, чтобы определить стабильность выпуска.
Итак, до версии 1.0 вы должны иметь 1.0 beta 1, 1.0 beta 2 и т.д. Это дает пользователям более четкое представление о том, какой основной релиз бета-версии ведет и позволяет избежать путаницы с любыми версиями поддержки, которые вы могли бы выпустить за это время.
Важно то, что вам нужно дистанцироваться между выпуском исправления (который должен повысить стабильность) и бета-версией (что может снизить стабильность).
Ответ 2
Одно очень практичное решение - именовать ваши итерации тестирования номерами релизов (например, My Awesome App r1392).
Apple, Microsoft и многие другие делают это для своих внутренних ревизий и выпускают только "реальные" номера версий для версии, продвигаемой их клиентам.
Ответ 3
Если вы используете старую версию Семантическое исполнение, (от до 2011-03-27), этот раздел имеет значение:
Специальный номер версии МОЖЕТ быть обозначается добавлением произвольного строка сразу после патча версия. Строка ДОЛЖНА быть включена только буквенно-цифровых символов плюс тире [0-9A-Za-z-] и ДОЛЖНЫ начать с альфа-символ [A-Za-z]. Особый версии удовлетворяют, но имеют более низкую приоритет, чем связанный с ним нормальный версия. Предпочтение ДОЛЖНО определяемый лексикографической сортировкой ASCII заказ. Например: 1.0.0beta1 < 1.0.0beta2 < 1.0.0.
Ответ 4
Номера версий полностью зависят от вас. Вы можете назвать их после названия животных или городов или использовать номера.
Многие проекты интересуются, что делать с номерами бета для следующего программного обеспечения gen (2.0, 3.0 и т.д.)
И что бы вы ни делали, просто помните, что вы можете делать все, что хотите. Поскольку номера версий являются маркетинговыми. Это просто для пользователей, чтобы узнать, где находится эта версия.
Так называя его 2.0 Beta 1, Beta 2 и т.д. будет работать нормально и самое главное. Пользователи поймут.
Ответ 5
Я бы рассмотрел бета-версии как незначительные изменения в "нулевой" версии приложения, поэтому бета-1 будет 0.1, бета 2 будет 0.2. и т.д.
Ответ 6
1.2.3 - Где "1" - это основные версии версий, а не бета-версия бета-версии будет 1.0, "2" будут основными релизами, включая новые функции, "3" - это небольшие выпуски. Если вам нравится, вы можете добавить еще один после этого, который может быть как ваш идентификатор фиксации версии или что-то в этом роде... но я уклоняюсь от этого.
