Какая схема номера версии для плохо спланированного, разветвленного и шизофренического применения - PullRequest
5 голосов
/ 12 мая 2009

Я ищу схему / схему / систему нумерации версий для приложения, которое в настоящее время разветвлено на несколько версий с датами выпуска в стиле игры . Это сделало версионирование кошмаром. Я хотел бы просто использовать типичный Major.Minor.Revision , однако это быстро сломается для меня, как сейчас все происходит здесь.

Вот мой инвентарь ...

  • 1.0.0 - производственная версия.
  • 1.0.1 - Рабочая версия ревизия версия с исправлением ошибок.
  • 1.1.0 - Производство второстепенная версия с новыми функциями, которые должны появиться в июле (необходимо соблюдать правила).
  • 1.2.0 - Производственная вспомогательная версия с новыми функциями для интеграции с еще не выпущенной, еще находящейся в разработке Системой A .
  • 2.0.0 - Разработка major версии "2.0" продукта (код перенесен на новую платформу, удобство использования улучшено).

И чтобы сделать его более увлекательным, они планируют еще один проект (новые функции) для интеграции с другой системой.

  • 1.3.0 - Производство второстепенная версия с новыми функциями, интегрирующимися с Система B .

В добавление к сложности добавляется тот факт, что мы не знаем точно, когда (читай: порядок, в котором) они «сработают». Если одна из систем, с которой мы интегрируемся, задерживается, руководство меняет график выпуска. Таким образом, сегодняшняя версия 1.2.0 может быть отложена, и тогда сборка, помеченная как 1.3.0, будет вначале сброшена. Координация с QA уже достаточно сложна без изменения меток версий в конце цикла.

Вопросы? Мысли? Мелкие пушистые животные?

мир | dewde

Ответы [ 7 ]

8 голосов
/ 12 мая 2009

Звучит так, будто вы не хотите использовать номера версий специально. Вы можете использовать кодовые имена (Windows делала это с каждым из своих выпусков до их выпуска). В основном вам нужно нечто большее, чем числа, чтобы различить в доме , о какой отрасли вы говорите. По мере выпуска версий вы можете наносить на них штамп Major.Minor.Revision, но до тех пор вам нужно назвать их так, чтобы их можно было узнать.

Разделите их на ветви и подотрасли. Убедитесь, что все, что зависит от более высокой ветви, имеет производное имя. Таким образом, вы можете вызвать ветку ProductionMac и ветку ProductionWindows, и вы сразу узнаете, что они не должны быть объединены, и что они оба являются производными.

Самая важная вещь для поддержания - это структурная иерархия. Номера версий делают это довольно хорошо, но вы должны продолжать добавлять «.» для каждого нового слоя, что раздражает и совершенно неописуемо (очень похоже на присвоение имен вашим переменным variableOne, variableTwo, variableThree) Итак, убедитесь, что, как бы вы ни выбрали, чтобы пометить каждую ветку, все еще очевидно, какие ветви связаны с какими другими ветвями.

5 голосов
/ 12 мая 2009

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

Или, назовите каждый выпуск после того, как проект, который его породил («Переработка пользовательского интерфейса», «Июньское обслуживание» и т. Д.), А затем присваивайте ему номер версии только после его запуска?

1 голос
/ 12 мая 2009

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

Добавление номера версии / сборки к вашей версии может помочь вам сопоставить это внутреннее кодовое имя с внешним номером версии (и может помочь в связи с QA).

Например:
Регламент Compliance r1234 соответствует версии 1.1.0.1234.

1 голос
/ 12 мая 2009

Я бы использовал словарь для сопоставления между внутренними номерами разработки и внешними номерами «выпуска», затем использовал внутренние номера разработки для внутреннего использования и выставлял номера «выпуска» только тогда, когда вы готовы выпустить его из разработки.

Бонусные баллы, если вы используете промежуточную карту с использованием иррациональных чисел. "Как идет разработка версии 3.14159?" «О, неплохо, но я все еще исправляю ошибку, обнаруженную в выпуске 2.71828183». "Что? Эта ошибка? Она должна была быть исправлена ​​в минорном выпуске 1.73205!" : -)

0 голосов
/ 12 мая 2009

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

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

"Вот новое соответствие нормативно-правовые акты. Если они не живут 15 июля нас оштрафуют на 500 000 долларов. За день. "

"Что? Когда ты получил это?"

«В июле прошлого года. распределение? "

** facepalm **

Я все еще думаю, что ответ Девинба лучший. Но я хотел бросить это здесь для других в этой дилемме.

мир | dewde

0 голосов
/ 12 мая 2009

в предыдущих сообщениях.

Наша система сборки увеличивает номер сборки после каждой сборки (независимо от того, будет ли она выпущена), что и используется dev / QA для идентификации сборок. Финальная версия # становится доступной ТОЛЬКО для внешнего мира при выпуске QA. Таким образом, существует действительно несколько сборок 1.3.0.x, но только одна верная 1.3.0.

0 голосов
/ 12 мая 2009

Исходя из того, что вы описываете, я согласен с первой парой постов. Значимые, уникальные имена, относящиеся к области действия / набору возможностей, вероятно, являются подходящим вариантом для каждой ветви. Пронумерованные версии кажутся разумными в каждой названной ветви.

То, что вам действительно нужно ... это ярлыки в стиле Gmail ... для управления версиями!

...