Лучшая практика: управление версиями программного обеспечения [закрыто]


211

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

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


2
Что делает ваш инструмент контроля исходного кода? Вы должны использовать один. Какой вы используете?
S.Lott

3
Я немного опоздал ... но дурак stackoverflow.com/questions/615227/how-to-do-version-numbers
вывод


1
@DaveGregory имеет не основанный на мнении ответ на вопрос. Эта ссылка на semver.org подробно описывает семантику версий. Такая же схема обычно используется большинством проектов Google, включая Android. Более того, в Томе Престон-Вернере мы можем найти такой же заслуживающий доверия голос, как и любой другой на эту тему.
Рахул Мурмурия

Ответы:


125

Вы должны начать с версии 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 (вы исправили некоторые ошибки).

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


У меня вопрос по поводу вашего ответа: если я работаю с версией 1.0.0.0 и внедряю незначительные, меньшие или большие изменения, а также хочу использовать номер сборки. На какой номер версии мне нужно добавить версию сборки? Представьте, я перехожу с 1.0.0.0 на 1.0.1.0. На каком номере я должен поставить номер сборки? И, в финальной версии, будет ли он также иметь номер сборки на свой номер версии (1.0.1.234)?
VansFannel

@VansFannel, я ожидал бы, что номер сборки будет сбрасываться в 0 каждый раз, когда вы поднимаете любое большее число.
Джеффри Кемп

@JeffreyKemp Да, я так думаю. Но на работе мы используем номер дня в году, и мне это не нравится.
VansFannel

Тьфу, мне это тоже не понравится :(
Джеффри Кемп

2
Следует также отметить, что изменения в основных версиях обычно не имеют обратной совместимости. Инкременты в минорной версии обратно совместимы в основной версии. Переход от жестко запрограммированной реализации MySQL к общей реализации может быть основной версией из-за размера изменения, но также может рассматриваться как изменение функции (незначительное), поскольку оно остается обратно совместимым.
ГВС


42

Я в основном следую этой схеме:

  • начать с 0.1.0

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

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

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

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


Что если у меня более 9 функций, могу ли я написать x.20.0?
Джемшит Искендеров

@JemshitIskenderov Конечно можно.
Павел С.

35

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

хуг

Куда:

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

Пример:

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

36
Я бы предложил использовать эту схему без пролонгации 9 -> 0 в числе «функция» / «исправление», просто перейдите к 10! 10 незначительных обновлений по-прежнему являются второстепенными, если они выпускались постепенно, в 1.10.0 или 1.1.10 нет ничего плохого.
ttarik

4
..и продолжай расти. Что, если у вас действительно есть 23 функции для реализации до v.2? И затем 30 исправлений в этой последней функции? У вас будет версия 1.23.30. Основные выпуски версий - это большие абстрактные концепции с определенными вехами, нет необходимости произвольно придерживаться правил десятичного подсчета.
brianclements

11

Мы используем ABCD где

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

5

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

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

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

5

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

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


2

Основной ответ - «Это зависит».

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

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

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


2

Как говорит Махеш: я бы использовал версию XYZ

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

Вы можете добавить дату и время, возможно, вместо z.

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


2

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

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


2

Мы придерживаемся abc подхода, как:

увеличивайте «a», если в приложении произошли серьезные изменения. Как мы обновляем приложение .NET 1.1 до .NET 3.5

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

увеличить 'c', если в коде исправлены некоторые дефекты.


0

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

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

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

Я не отслеживаю сборки, поэтому мне нравится использовать шаблон abc, если не используется исправление. Когда мне нужно применить исправление, я применяю параметр d как дату со временем. Я принял параметр времени как d, потому что всегда есть потенциал нескольких в день, когда вещи действительно взрываются в производстве. Я применяю сегмент d (ГГГГММДДЧЧНН) только тогда, когда меняю производственное исправление.

Лично я не был бы против программной схемы va.b revc, где c - ГГГГММДДЧЧММ или ГГГГММДД.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.