Какую метку версии использовать для разветвленного проекта maven?

Мне часто приходится разворачивать проект Java, который использует Maven (обычно на github).

Когда я форкирую проект и вношу свои изменения, я вообще хочу вырезать выпуск в свой собственный (но в Интернете) репозиторий maven.

Таким образом, вопрос о том, какой должна быть метка версии для моей пользовательской версии. Я не могу сделать SNAPSHOT, поскольку мне нужно, чтобы он был выпуском. Иногда я суффикс проекта .ADAMGENT (потому что я нарциссист). Допустим, что fork 1.0.4-SNAPSHOT. Я могу изменить его на 1.0.4.ADAMGENT. Я понятия не имею, если это хорошая идея. В некоторых случаях я даже не могу суффиктировать его с помощью .ADAMGENT, поскольку Spring Gradle инструментам сборки это не нравится. Поэтому для проектов Spring я делаю .ADAMGENT.RELEASE или .ADAMGENT.M1, если это веха.

Что делают другие?

Обновление:, хотя я сказал, что вилка меня больше изменяет уровень патча. С другой стороны, щедрость (другим пользователем) может быть для fork и/или патча

ОТВЕТЫ

Ответ 1

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

1.0.4-ADAMGENT-1

за которым последует 1.0.4-ADAMGENT-2, если вам нужно сделать другое изменение.

Определенно держите идентификаторы artifact и group от исходного проекта, а также версию, на которой вы основываете свои изменения, это будет полезно позже, если вам когда-нибудь понадобится выяснить, какая версия вы были работа над. И это облегчает переход на официальную версию, если ваши изменения включены вверх по течению.

Ответ 2

Поскольку вы используете forking, используйте другой идентификатор группы.

Реальность такова, что как только вы начинаете вносить изменения в свою локальную вилку, это другой артефакт. Артефакт, созданный вашей организацией, а не тот, с которого вы его взяли.

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

Например:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.adamgent</groupId>
    <artifactId>project-xyz</artifactId> <!-- same artifact ID -->
    <version>1.0.0-RELEASE</version>
    <name>My Project XYZ</name> <!-- different display name -->
    <description>My fork of project XYZ created from v5.42.0 of original sources.</description>
    ....

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

  • вы можете более легко отслеживать свои вилки в Nexus
  • вы устраняете любую путаницу, которая может возникнуть из-за наличия артефактов из организации, которую они не создавали.
  • вы останетесь в стандартных рекомендациях для идентификаторов версии Maven.

Ответ 3

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

например.

1.0.4-2011-09-12.ADAMGENT

Ответ 4

Я придумал свое решение. Я не буду отмечать его правильно, так как я думаю, что у @DavidH есть некоторые действительные точки, и если у Maven был уровень конфигурации, который Ivy имеет для замены groupid (и/или я выяснил в сонатипе, как это сделать), я, вероятно, верный. В противном случае я твердо верю, что вилка должна быть другим пространством имен, а имена пакетов Java должны быть несколько встроены в ваши проекты groupid. Также для моей ситуации мне часто нужно сделать это для исправления ошибок, чтобы она не была вилкой.

Это то, что я делаю, и оно основано на том, как maven читает номера версий и что делает Sonatype:

Сначала я настраиваю свой собственный публичный, но не центральный репозиторий, где я буду публиковать свою версию. Вы можете использовать github и/или googlecode для размещения такого репо. В сети есть руководства о том, как это сделать и как публиковать в нем, поэтому я не буду вникать в это.

Для номеров версий я следую этому формату, кроме Spring, потому что система сборки Spring имеет странные требования, как указано в моем вопросе:

1.0.4-ADAMGENT-1

Некоторые изменения и релиз:

1.0.4-ADAMGENT-2

Вы можете видеть, что Maven будет в основном понимать этот формат глядя на код. Проблема заключается в квалификаторе ADAMGENT. Maven только понимает несколько отборочных "альфа" , "бета" , "веха" , "rc" , "моментальный снимок" , "," sp "и" sp ", ga" , "final" , "cr" должным образом.

Те, в которых это не так, лексически упорядочены (ADAMGENT в этом случае), и это нормально, и я предполагаю, что вы можете увеличить инкрементную версию (4), если это проблема.