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

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

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

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

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

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

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

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

• начать с 0.1.0

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

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

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

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

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

хуг

Куда:

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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