Как номер версии проекта?

У меня есть проект mavenmulti-module с более чем 6 детскими модулями. Если команда из 3 работает параллельно, принимая в качестве своей задачи 2 sub-modules, то как увеличить номер версии.Как номер версии проекта?

тогда как я следую Major.minor.patch-meta формат для нумерации версий в циклах выпуска.

Project A 
    -- sub-module-assembler 
     pom.xml 
    -- sub-module-1 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
    -- sub-module-2 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
    -- sub-module-3 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
    -- sub-module-4 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
    -- sub-module-5 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
    -- sub-module-6 
     -sub-sub-module-1 pom.xml 
     -sub-sub-module-2 pom.xml 
     pom.xml 
--pom.xml

Точное использование увеличения и уменьшения номера версий в parallel programming, принимая во внимании ключевой вещи, чтобы быть уведомлены в это какое-то sub-modules в этом проекте полностью зависит от какого-либо другого sub-module, если это так, то как номер версии точно в то время как развитие идет параллельно, а также в определенном порядке?

Я не ясно, о ниже, но это правильный способ нумерации версии

Если мне нужно сделать meta release в случае ошибка исправления, например, альфа, бета, гамма и т.д.,
Если мне нужно сделать в случае завершения feature[sub-sub-module-x] в patch release в sub-module в то время как я использую second level+sub-modules например, 0.1.1-альфа, 0.1.2-альфа и т.д.,
Должен ли я сделать minor release в случае завершения sub-module, например 0.2.0-alpha, 0.2.0-RC и т. Д.,.
Таким образом, после интегрирования всех РЦ 0.2.0-RC + 0.3.0-RC + 0.4.0-RC и т.д. должны мне нужно сделать major release, как 1.0.0-RTM и т.д.,

Так понимание вышеупомянутого потока - бит-сочетанный.

Есть ли способ автоматизировать build numbering в проекте, чтобы поддерживать чистоту build release numbers. Пожалуйста, предоставьте решение.

Благодаря

источник

2014-05-05 Bachan-user3143666

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

Проект выглядит довольно большим. Первая группа, которую я буду делать, - это ответственность. Существуют ли модули, которые ограничены определенной командой разработчиков? Или все это поддерживается «все-в-одном»? Надеюсь, вы сможете разбить его немного. Как только вы узнаете о функциях модуля (модулей), вам необходимо определить некоторый жизненный цикл. Как и как часто создается релиз (или исправление, патч) и кем? Если каждый будет следовать одному ритму, вы можете поделиться одной версией и выпустить все дерево. Но обычно это не так в крупных проектах. Он также вводит побочные эффекты во время разработки, если многие люди используют одну версию.

Если вы не планируете выпускать полное дерево сразу, вы можете разделить его более последовательно. Вы все равно можете использовать общий родительский pom.xml (но один с выпущенной версией).

Я бы определил одну версию для модулей в родительском pom.xml и наследовал ее. Поэтому в подмодулях нет отдельной версии. Кроме того, каждая команда, которая зависит от других модулей, не должна использовать зависимости SNAPSHOT для работы других команд. Они могут использовать только выпущенную версию (будь то BETA или RC1).Важно сохранить воспроизводимые сборки. Например: «Никаких зависимостей от моментальных снимков от артефактов, за которые вы не отвечаете (вы контролируете, какие изменения и когда)»

Что касается самого версирования: в сомнении более простой вариант может быть лучше. Вся метаинформация может только путать фактическое состояние?

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

Если вы еще ничего не выпустили, планируйте заранее. Каждая итерация обычно представляет собой изменение API (поэтому на самом деле это будет основной выпуск). Это приведет к выпуску версии 18.0.0 (после 18 итераций). Поэтому обычно второстепенная версия используется для обозначения итераций, а версии патчей указывают на некоторые исправления для стабилизации этой версии. Таким образом, основные версии выбираются скорее из маркетингового аспекта, чем из технического.

Это также зависит от типа программного обеспечения, которое вы создаете (продукт, решение для дома, некоторые дополнительные услуги для вашего ландшафта). Продукты имеют более четкое управление версиями, они обычно используют часть META для указания итераций и номеров major.minor.patch, чтобы указать, что происходит. Эта стратегия («указать, какие изменения ожидать») может помочь в том, что вы делаете?

Так что, надеюсь, это не вызвало больше вопросов, чем у вас было в начале :)

источник

2014-05-05 12:03:26 wemu

ответ

Смежные вопросы