Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-699

release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: update-versions
    • Number of attachments :
      1

      Description

      The documentation
      http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html
      states "The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used."
      That's not true, as releaseVersion is not supported:
      http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion

      This means, that if you do this:
      mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0
      that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT.

        Activity

        Hide
        Geoffrey De Smet added a comment -

        I patched this, please pull my changes:
        https://github.com/apache/maven-release/pull/2

        This fix also fixes the fact that RewritePomVersionsPhase.getOriginalVersionMap() was inaccurate (although that did not seem to have any bad effect).

        Show
        Geoffrey De Smet added a comment - I patched this, please pull my changes: https://github.com/apache/maven-release/pull/2 This fix also fixes the fact that RewritePomVersionsPhase.getOriginalVersionMap() was inaccurate (although that did not seem to have any bad effect).
        Hide
        Brett Porter added a comment -

        Would you mind attaching it as a patch to JIRA? We can't use the github feature directly. Thanks!

        Show
        Brett Porter added a comment - Would you mind attaching it as a patch to JIRA? We can't use the github feature directly. Thanks!
        Hide
        Geoffrey De Smet added a comment -

        No problem I did:
        git format-patch 124470185de7f3218380f2d7c0a384495ebb9955
        and attached that file.

        That's probably a git patch, not an old-school patch. If you want an old-school patch, please inform me how I can create that from a command line or intelliJ after the changes have already been committed.

        Show
        Geoffrey De Smet added a comment - No problem I did: git format-patch 124470185de7f3218380f2d7c0a384495ebb9955 and attached that file. That's probably a git patch, not an old-school patch. If you want an old-school patch, please inform me how I can create that from a command line or intelliJ after the changes have already been committed.
        Geoffrey De Smet made changes -
        Field Original Value New Value
        Attachment 0001-MRELEASE-699-release-update-versions-should-support-.patch [ 56258 ]
        Hide
        Jörg Schaible added a comment -

        The more interesting question is: Why do you want to do this? IMHO this functionality was not implemented on purpose, because you should never have locally a non-SNAPSHOT version.

        Show
        Jörg Schaible added a comment - The more interesting question is: Why do you want to do this? IMHO this functionality was not implemented on purpose, because you should never have locally a non-SNAPSHOT version.
        Hide
        Geoffrey De Smet added a comment - - edited

        I can't use the release:prepare goal for various reasons [1],
        but when I am releasing, I do need to be able to change all my versions from SNAPSHOT to release, tag and deploy and then from release to SNAPSHOT again.

        [1] Here's why I can't use the release:prepare goal:

        • Our project has several git repositories with SNAPSHOT dependencies between them: https://github.com/droolsjbpm (guvnor depends on drools, drools depends on droolsjbpm-knowledge, ...). Having them all in a single git repo (of 1.2 GB) was unworkable for many reasons, yet for the time being they do continue to share the same release lifecycle.
        • We use tycho for our eclipse plugin (see droolsjbpm-tools). The release plugin and tycho don't integrate as far as I know.

        So I am creating release scripts here (to avoid having to manually change versions, tag, etc on every single release):
        https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script/release
        and these require this patch.

        Show
        Geoffrey De Smet added a comment - - edited I can't use the release:prepare goal for various reasons [1] , but when I am releasing, I do need to be able to change all my versions from SNAPSHOT to release, tag and deploy and then from release to SNAPSHOT again. [1] Here's why I can't use the release:prepare goal: Our project has several git repositories with SNAPSHOT dependencies between them: https://github.com/droolsjbpm (guvnor depends on drools, drools depends on droolsjbpm-knowledge, ...). Having them all in a single git repo (of 1.2 GB) was unworkable for many reasons, yet for the time being they do continue to share the same release lifecycle. We use tycho for our eclipse plugin (see droolsjbpm-tools). The release plugin and tycho don't integrate as far as I know. So I am creating release scripts here (to avoid having to manually change versions, tag, etc on every single release): https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/tree/master/script/release and these require this patch.
        Hide
        Brett Porter added a comment -

        There's several things here:

        • I'm not quite sure of the motivation for update-versions in the first place - maybe we should recommend the versions plugin instead
        • regardless of the above, we need to document the differences, and fix the misleading statement (or apply this patch)
        • we still need to look at the one line change that appears to be correct but doesn't reference a specific fix
        Show
        Brett Porter added a comment - There's several things here: I'm not quite sure of the motivation for update-versions in the first place - maybe we should recommend the versions plugin instead regardless of the above, we need to document the differences, and fix the misleading statement (or apply this patch) we still need to look at the one line change that appears to be correct but doesn't reference a specific fix
        Hide
        Geoffrey De Smet added a comment -

        There is an alternative plugin to change the versions:
        http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html

        The release plugin goal "update-versions" should probably be deprecated in favor of that plugin.
        http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html

        Show
        Geoffrey De Smet added a comment - There is an alternative plugin to change the versions: http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html The release plugin goal "update-versions" should probably be deprecated in favor of that plugin. http://maven.apache.org/plugins/maven-release-plugin/update-versions-mojo.html
        Hide
        Tomislav Nakic-Alfirevic added a comment -

        @Geoffrey: Is this the one you wanted to link to?

        http://mojo.codehaus.org/versions-maven-plugin/

        mvn versions:set -DnewVersion=2.0.0

        Show
        Tomislav Nakic-Alfirevic added a comment - @Geoffrey: Is this the one you wanted to link to? http://mojo.codehaus.org/versions-maven-plugin/ mvn versions:set -DnewVersion=2.0.0
        Hide
        Geoffrey De Smet added a comment -

        @Tomislav: yes

        Show
        Geoffrey De Smet added a comment - @Tomislav: yes
        Robert Scholte made changes -
        Description The documentation
          http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html
        states "The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used."
        That's not true, as releaseVersion is not supported:
          http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion

        This means, that if you do this:
          mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0
        that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT.
        The documentation
          http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html
        states "The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used."
        That's not true, as releaseVersion is not supported:
          http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion

        This means, that if you do this:
          {{mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0}}
        that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT.
        Component/s update-versions [ 15464 ]
        Hide
        Torsten Liermann added a comment -

        This is also true for the branch goal. Specifying a -DreleaseVersion=1.0 the release plugin generate as release version 1.0-SNAPSHOT. But when the plugin ask for the branch version, the created branch pom will be correct.

        Show
        Torsten Liermann added a comment - This is also true for the branch goal. Specifying a -DreleaseVersion=1.0 the release plugin generate as release version 1.0-SNAPSHOT. But when the plugin ask for the branch version, the created branch pom will be correct.
        Robert Scholte made changes -
        Labels github-pullrequest

          People

          • Assignee:
            Unassigned
            Reporter:
            Geoffrey De Smet
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: