maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Klein (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MRELEASE-897) support multiple release versions
Date Fri, 12 Oct 2018 19:05:00 GMT

    [ https://issues.apache.org/jira/browse/MRELEASE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648284#comment-16648284
] 

Carsten Klein edited comment on MRELEASE-897 at 10/12/18 7:04 PM:
------------------------------------------------------------------

[~rfscholte] Why do the other requirements require a new Jira issue? This is part of the conversation
that we have on solving the multi version, multi module, multi parent issue, namely MRELEASE-897.

 

As for the gitflow thing, auto merge, branch and whatnot, I only mentioned that to provide
a bigger picture.

The actual solution would be to just work on the release plan, do the tagging and leave the
release branch as is, eventually push it and existing tags to the remote as is the standard
when doing a release:prepare.

Existing plugins that implement the "gitflow" and also the multi-module-maven-plugin, reimplement
the functionality of the release plugin. And while the multi-module-maven-plugin only works
with gitscm, it will also generate version numbers that cannot be parsed by the maven-version
plugin or by SemVer, e.g. 1.0.0.1234, as it puts the build number into the version instead
of making it part of the tag.

However, and just like maven-release, jgitflow by Atlassian and the other gitflow plugin,
will fail on multi-version, multi-module, multi-parent scenarios. And I strongly believe that
MRELEASE-897 is a very good home for tackling these issues. The other plugins will then either
become obsolete or adapt accordingly.

So the initial plan is to just implement the ReleasePlan, allowing users to define the versions
/ strategies for versioning / strategies for scm tag naming, and also to make sure that the
maven-release plugin will create tags in the scm according to the plan, also pushing these
scm tags as required.


was (Author: silkentrance):
[~rfscholte] Why do the other requirements require a new Jira issue? This is part of the conversation
that we have on solving the multi version, multi module, multi parent issue, namely MRELEASE-897.

 

As for the gitflow thing, auto merge, branch and whatnot, I only mentioned that to provide
a bigger picture.

The actual solution would be to just work on the release plan, do the tagging and leave the
release branch as is, eventually push it and existing tags to the remote as is the standard
when doing a release:prepare.

Existing plugins that implement the "gitflow" and also the multi-module-maven-plugin, reimplement
the functionality of the release plugin. And while the multi-module-maven-plugin only works
with gitscm, it will also generate version numbers that cannot be parsed by the maven-version
plugin or by SemVer, e.g. 1.0.0.1234, as it puts the build number into the version instead
of making it part of the tag.

However, and just like maven-release, jgitflow by Atlassian and the other gitflow plugin,
will fail on multi-version, multi-module, multi-parent scenarios. And I strongly believe that
MRELEASE-897 is a very good home for tackling these issues. The other plugins will then either
become obsolete or adapt accordingly.

So the initial plan is to just implement the ReleasePlan, allowing users to define the versions
/ strategies for versioning / strategies for scm tag naming, and also to make sure that the
maven-release plugin will create tags in the scm according to the plan, creating tags as
required.

> support multiple release versions
> ---------------------------------
>
>                 Key: MRELEASE-897
>                 URL: https://issues.apache.org/jira/browse/MRELEASE-897
>             Project: Maven Release Plugin
>          Issue Type: Improvement
>            Reporter: Romain Manni-Bucau
>            Priority: Major
>
> In some project multiple versions are used (tomee release = tomee + openejb releases
for instance). It is not always possible to split the project in sub projects and then it
is not possible to use maven release plugin. Idea would be to support a whitelist of artifacts
(a list of patterns would be great).
> {code}
> <releaseVersions>
>   <releaseVersion>org.superbiz.component:*:1.0.1</releaseVersion>
>   <releaseVersion>org.superbiz.component:*:4.5.8</releaseVersion>
> </releaseVersions>
> {code}
> For instance or even:
> {code}
> <releaseVersions>
>   <releaseVersion>org.superbiz.component:*:@major.@minor.@patch</releaseVersion>
>   <releaseVersion>org.superbiz.component:*:(@major + 3).@minor.@patch</releaseVersion>
> </releaseVersions>
> {code}
> to avoid to change it for each release.
> This of course would imply the CLI to ask for the multiple versions and not only one
even when autoSubModules is set to true (it would just group by versions)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message