Могу ли я получить совет по нумерации версий? - PullRequest
5 голосов
/ 10 марта 2009

Наш продукт имеет долгую историю (около 12 лет).

Его происхождение находится в VB3 (версия 1) и более поздних версиях VB6 (версия 2). (Номера версий были "собачьим завтраком", а контроль версий был кошмаром.

Я здесь уже несколько лет. У нас есть версия 3 в разработке на платформе .Net, но версия 2 продолжает поддерживаться с периодическими выпусками - около 3 или 4 в год.

Я ввел ночные автоматические сборки еще при запуске, и номер версии нашего продукта был 2.2.2. Все планировали просто выпустить 2.2.3, но автоматизированный процесс сборки и «интересная» система нумерации из 3 частей VB6 означали, что нам нужно использовать третью часть - номер сборки / ревизии - какой бы она ни была.

Итак, мы выпустили версию 2.3 (с номером сборки «что угодно») и приступили к работе над 2.4 (увеличивая номера сборки по ночам), затем 2.5, затем 2.6 и т. Д.

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

Согласованность обеспечена. Теперь мы достигаем 2,9. Мы собираемся перейти к 2.10 (два целых девять, до двух десятых). К сожалению, нетехнические ребята читают это как рациональное число (два - точка первая). Они не могут понять, почему мы не просто переходим к версии 3.0 - например, к подсчету. (Номер сборки отображается только на экране «Справка / О программе» в целях поддержки).

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

Есть ли правильный способ продолжить здесь? (2.10 или 3.0 или что-то лучше - или это вообще имеет значение?)

(NB. Я сделал несколько шагов, чтобы номер версии теперь отображался как 2,09 вместо 2,9 (на нашем веб-сайте, заставке продукта и в других местах общего пользования и т. Д.), Чтобы при мы переходим к 2.10, это может иметь больше смысла, но это потенциально столь же запутанно, потому что 2.09 - это на самом деле меньшее рациональное число, чем 2.8 ...)

См. Также:

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

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

Как узнать, какой номер версии использовать?

Ответы [ 12 ]

9 голосов
/ 10 марта 2009

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

6 голосов
/ 10 марта 2009

Остальные ответы только наполовину правы. Номера версий имеют значение, которое вы им даете, но они также имеют значение, которое им дают другие. Ваше собственное значение действительно не имеет значения, так как вы не будете там, чтобы исправить своих пользователей. Если они думают, что переход с 2,9 на 3,0 - это огромный скачок, то они так и сделают. Если они боятся использовать версии x.0, то они не будут. Если они используются для нечетных выпусков, являющихся альфа-версиями, они не будут их использовать.

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

Проблема в том, что номера версий означают разные вещи для разных людей. Есть некоторые вещи, которые вы можете предсказать. Как я упоминал выше, люди будут подозревать релизы x.0. Они ожидают больших изменений с 2.x до 3.x. Если вы хотите попробовать сыграть, что пришло, продолжайте.

Есть два существенных атрибута номеров версий. Во-первых, они всегда должны идти вверх. Во-вторых, они должны легко сортироваться. Первое очевидно, но второе часто нарушается. Рассмотрим версию 2.9 -> 2.10. Численно говоря, 2,9 больше, чем 2,10. Вы должны учитывать их основные / второстепенные номера версий для правильной сортировки. Из этого следует путаница относительно того, следует ли 2.10 или 3.0 за 2.9. Даже если мы знаем правила сортировки, это все равно кажется неправильным. По этой причине я всегда дополняю свои версии. 2.09 сопровождается 2.10. Он сортируется правильно как по числу, так и по точечной паре.

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

Я могу пойти лучше. Существует четкое значение, которое вы можете дать номеру версии, что-то полезное. У нас есть проблема в мире CPAN людей, которые не обновляют свои модули, потому что они используют версию 1.03, а последняя версия - 1.07. Зачем обновлять? То, что это не показывает, - то, что было четыре года между 1.03 и 1.07. Microsoft поняла, что именно поэтому мы покупаем Office 2009 вместо Office 12 (если вы не выпускаете часто, это может привести вас в замешательство, кому нужна Windows 98 в 2001 году?) Это прямо в номере версии. «Виджеты 2007» говорит вам, может быть, вам стоит поискать обновление.

Я использовал даты ISO в качестве версий. Если вы выпустили сегодня, это будет версия 20090309. Если вам нужно было выпустить два за один день, отметьте час и минуту в конце: 20090309.2051. Это легко. Это всегда идет вверх. Он передает какое-то однозначное значение пользователю о выпуске. Вот пример .

Я сейчас использую Семантическое управление версиями . Он использует пунктирную тройку для передачи трех важных частей информации. API был сломан? Были ли добавлены функции? Это просто исправление ошибки? Пользователь должен знать, что ваш проект использует семантические версии, что является недостатком по сравнению с версиями дат ISO. Преимущество заключается в типе информации, которую она передает, и в том, что она четко определена.

6 голосов
/ 10 марта 2009

Как вы сами управляете версией своего программного обеспечения. Не существует «правильного» или «неправильного», кроме того, что лучше всего с точки зрения обслуживания, управления выпусками и поддержки клиентов. Для вас важно контролировать управление версиями - чтобы вы понимали это, чтобы все, кто работает с продуктом, понимали его и чтобы оно не вызывало проблем в дальнейшем. Нет смысла переходить с 2,9 на 2,10, в отличие от 3,0, кроме значения , которое вы даете ему.

4 голосов
/ 10 марта 2009

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

  • 2.8.0
  • 2.9.0
  • 2.10.0
  • 2.11.0
  • ...

Кроме того, в диалоговых окнах about прикрепите дату сборки (гггг-мм-дд) рядом с номером версии. Если клиента путают с номерами версий, он может просто сравнить даты, что на 1015 * намного более интуитивно понятно для обычных людей.

4 голосов
/ 10 марта 2009

Вы можете сделать 2.9.1 или даже 2.10.1, но есть много проектов, которые продолжают считать. 2.10, 2.11 12 13 и т. Д.

3 голосов
/ 10 марта 2009

Если 2.10 вызывает путаницу, пропустите ее и перейдите к 2.11. Будьте готовы к той же проблеме с 2.20, хотя:)

3 голосов
/ 10 марта 2009

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

2 голосов
/ 10 марта 2009

Я рекомендую отделить вашу маркетинговую версию от внутренних версий ваших библиотек DLL и еще много чего. У них разная семантика.

1 голос
/ 10 марта 2009

Вы должны сказать им, чтобы маркировать версию программного обеспечения способом, который не зависит от внутреннего номера версии. Например, iPhoto '09 - это версия iPhoto 8.x. Microsoft сделала то же самое.

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

1 голос
/ 10 марта 2009

В Википедии есть очень хорошая статья о версии программного обеспечения

Если вы работаете над длительным текущим проектом, идентификаторы на основе последовательности (например, 1.0, 2.0 и т. Д.) Не масштабируются.

Мне лично нравится (и я предпочитаю) схема управления версиями Ubuntu, которая использует год и месяц выпуска в своей версии. Например, Ubuntu 8.04 была выпущена в апреле 2008 года.

...