Гертьян Виленга
Управление версиями, тегирование и ветвление
Обычно мы используем тройной номер версии (abc):
- Последнее число (c) увеличивается с помощью нашего выпуска на две недели. Каждый модуль получает новую версию, даже те, которые не изменились. Когда в модуле исправлена ошибка prio 1, он выпускается отдельно с дополнительным номером патча (например, 1.0.20.1 для первого патча в версии 1.0.20). В этом случае тег 1.0.20 повышается до ветви (для всего репо, а не только для модуля). Изменения в ветке возвращаются по умолчанию.
- Второе число (b) увеличивается на вехи (примерно каждый квартал, т. Е. 4 раза в год).
- Первое число (а) будет меняться, вероятно, только один раз в год или два года.
специалист
Мы используем плагин релиза Maven, чтобы выполнить наш релиз. На этапе подготовки номера версии модуля обновляются до следующей версии (1.0.19 -> 1.0.20 или -> 1.1 в случае выпуска этапа). На этапе выполнения модули загружаются в репозиторий релизов в Sonatype . Когда мы закрываем репозиторий Sonatype, модули синхронизируются с центральным Maven.
Одна хитрость, которую мы используем с репозиторием релизов Maven, — это использование локального репозитория в качестве developerConnection :
<developerConnection>scm:hg:file://localhost${basedir}</developerConnection>
Таким образом, вы можете вручную отправить все изменения, сделанные в системе версий. Это избавляет от необходимости делать большую очистку после неудачного выпуска.
Хранилища
В настоящее время мы поддерживаем два репозитория, «core» и «extra». Модули и комплекты организованы так, как если бы они были одним хранилищем. Разница заключается в том, что дополнительный модуль в основном наборе будет расположен в другом хранилище исходного кода.
Оба репозитория имеют собственный модуль центра обновлений (модуль «uc-core» и модуль «uc-extra»). Центры обновлений указывают на файл catalog.xml, расположенный на нашем сервере, с версией major.milestone в своем пути, которая в настоящее время:
agrosense.nl/updates/core/1.0/catalog.xml
Таким образом, мы можем поддерживать обновления предыдущей версии этапа в переходный период. (И вообще API могут нарушить обратную совместимость только в новом выпуске.)
Поскольку в зависимости от наших основных API будут сторонние модули, переходный период может занять несколько недель.
Чтобы создать файл catalog.xml, нам нужно выполнить несколько ручных задач. Мы поддерживаем прикладной модуль modules-core и modules-extra. Они зависят от всех модулей, которые должны быть выпущены для этого хранилища. Мы генерируем catalog.xml, выполняя
$mvn clean package -Pdeployment
Затем нам нужно удалить все модули NetBeans из «catalog.xml» и очистить раздел лицензий. После очистки мы загружаем «catalog.xml» и «catalog.xml.gz» на наш сайт.