Выбор номера версии

Question

ДУБЛИРУЙТЕ

Как сделать номера версий?

---

Hello

Итак, я недавно увидел, что Groovy был выпущен до версии 1.6 , и во время прослушивания подкаста Java Posse они комментировали, как много всего было упаковано в этот релиз, что это должно было 2.0 выпуск.

Это заставило меня задуматься. Номера версий просто произвольны? Раньше я думал, что они имеют смысл, но я думаю, нет. Это все только на основе вехи и настроено на проект?

Как ваша команда контролирует номера версий и выпуски?

Заранее спасибо

Answer 1

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

Для маркетинга ответ: «Все, что вы хотите, чтобы ваши клиенты думали». В этом случае «новая основная версия», вероятно, должна сопровождаться номером основной версии.

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

Для технического использования ответ: «Какую бы информацию вы ни хотели закодировать для разработчиков». Там нет одного правильного способа сделать это; это зависит от ваших целей.

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

Answer 2

Они очень произвольны. Многим нравится иметь что-то вроде

[major].[minor].[release].[revision]

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

Хороший вопрос для увеличения основной версии может быть:

Если бы это был платный продукт, заплатили бы клиенты за обновление до более новой версии?

Если это так, возможно, было бы неплохо увеличить старшее число.

Answer 3

MajorRelease.MinorRelease.Hotfix

Answer 4

Номера версий произвольны, но есть некоторые правила для большого пальца (я думаю). Очень незначительные изменения или исправления обычно увеличиваются на 0.0.1, то есть V1 становится V1.0.1. Незначительные изменения в функциональности увеличиваются на 0,1.0, то есть V1.0.1 становится V1.1.0. Значительные изменения или перезаписи получают увеличение на 1,0.0, т.е. до V2.

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

Кроме того, IIRC, некоторые проекты, как правило, обозначают экспериментальные сборки с нечетными версиями и стабильными сборками как четные (поэтому V3 опасен, V4 стабилен).

Answer 5

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

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

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

Основные номера версий могут разбить все три формы.

Я написал больше об обосновании здесь .