Лучшая практика: Software Versioning

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

Но с чего начать запуск версии? 0.0.0? или 0,0? А потом, как я увеличиваю числа? основные изменения .minor? и не должно ли какая-либо фиксация системы контроля версий быть другой версией? или это только для версий, которые используются продуктивно?

ОТВЕТЫ

Ответ 1

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

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

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

Итак, если вы делаете серьезное изменение с версии 1.0.0.0 до версии 2.0.0.0 (например, вы изменили с WinForms на WPF). Если вы сделаете меньшее изменение, переходите от 1.0.0.0 до 1.1.0.0 (вы добавили поддержку png файлов). Если вы сделаете незначительные изменения, перейдите от 1.0.0.0 до 1.0.1.0 (вы исправили некоторые ошибки).

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

Ответ 2

Я бы использовал x.y.z тип версий

x - основной выпуск
y - незначительный выпуск
z - номер сборки

Ответ 3

Я в основном следую этому шаблону:

  • начать с 0.1.0

  • когда он готов, я разворачиваю код в исходном репо, тег 0.1.0 и создаю ветку 0.1.0, головка/соединительная линия становится 0.2.0-снимок или что-то подобное

  • Я добавляю новые функции только к соединительной линии, но backport фиксирует ветку и со временем освобождаю ее 0.1.1, 0.1.2,...

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

  • с этого момента каждый может решить, когда нужно увеличить основную версию...

Ответ 4

Я использую это правило для своих приложений:

x.y.z

Где:

  • x = номер основной версии, 1- ~.
  • y = номер функции, 0-9. Увеличьте это число, если изменение содержит новые функции с исправлениями ошибок или без них.
  • z = номер исправления, 0- ~. Увеличьте это число, если изменение содержит только исправления ошибок.

Пример:

  • Для нового приложения номер версии начинается с 1.0.0.
  • Если новая версия содержит только исправления ошибок, увеличьте номер исправления, чтобы номер версии был 1.0.1.
  • Если новая версия содержит новые функции с исправлениями или без ошибок, увеличьте номер функции и reset номер исправления до нуля, чтобы номер версии был равен 1.1.0. Если номер функции достигает 9, увеличьте номер основной версии и reset номер функции и номер исправления до нуля (2.0.0 и т.д.).

Ответ 5

Мы используем a.b.c.d, где

  • a - майор (увеличивается при доставке клиенту)
  • b - второстепенный (увеличивается при доставке клиенту)
  • c - ревизия (увеличивается на внутренние выпуски)
  • d - построить (с добавлением круиз-контроля)

Ответ 6

Еще одним примером подхода A.B.C является Eclipse Bundle Versioning. Пакеты Eclipse скорее имеют четвертый сегмент:

В Eclipse номера версий состоят из четырех (4) сегментов: 3 целых числа и строки, соответственно названной major.minor.service.qualifier. Каждый сегмент захватывает другое намерение:

  • основной сегмент указывает на поломку в API
  • второстепенный сегмент указывает "видимые извне" изменения.
  • сегмент службы указывает исправления ошибок и изменение потока разработки
  • сегмент классификатора указывает конкретную сборку

Ответ 7

Существует также схема управления версиями даты, например: YYYY.MM, YY.MM, YYYYMMDD

Это довольно информативно, потому что первый взгляд создает впечатление о дате выпуска. Но я предпочитаю схему x.y.z, потому что я всегда хочу знать точную точку продукта в ее жизненном цикле (Major.minor.release)

Ответ 8

Основной ответ: "Это зависит".

Какова ваша цель в управлении версиями? Многие люди используют version.revision.build и рекламируют версию version.revision для мира как версию выпуска, а не версию dev. Если вы используете "версию" для регистрации, вы быстро обнаружите, что ваши номера версий становятся большими.

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

Тем не менее, в конце концов, это зависит от вас, и это должно иметь смысл для вас.

Ответ 9

Как говорит Махеш: Я бы использовал x.y.z вид версий

x - основной выпуск y - незначительный выпуск z - номер сборки

вы можете добавить datetime, возможно, вместо z.

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

Ответ 10

Вы знаете, что всегда можете проверить, что делают другие. Программное обеспечение с открытым исходным кодом имеет тенденцию предоставлять доступ к своим хранилищам. Например, вы можете указать браузеру SVN на http://svn.doctrine-project.org и взглянуть на систему управления версиями, используемую реальным проектом.

Номера версий, теги, все там.

Ответ 11

Мы следуем подходу a.b.c, например:

increament 'a', если в приложении произошли серьезные изменения. Как мы обновляем приложение .NET 1.1 до .NET 3.5

increment 'b', если есть некоторые незначительные изменения, например, любые новые CR или Enhancement.

increament 'c', если в коде есть исправления.

Ответ 12

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

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

Я думаю, что наиболее приемлемый шаблон a.b.c. или a.b.c.d, особенно если у вас есть QA/Compliance в миксе. У меня было так много флэка, что я был регулярной частью версий, которые я отказался от мейнстрима.

Я не отслеживаю сборки, поэтому мне нравится использовать шаблон a.b.c, если не включено исправление. Когда мне нужно применить исправление, я применяю параметр d как дату со временем. Я принял параметр времени как d, потому что всегда есть потенциал нескольких в день, когда в производстве действительно взрываются вещи. Я применяю только d-сегмент (YYYYMMDDHHNN), когда я расхожусь для производственного исправления.

Я лично не буду возражать против программной схемы va.b revc, где c - YYYYMMDDHHMM или YYYYMMDD.

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