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

release:branch commits changes to tags/ directory

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-beta-7
    • Fix Version/s: None
    • Component/s: scm
    • Labels:
      None
    • Number of attachments :
      0

      Description

      It should be possible to create a branch from a tag using the release plugin without comitting changes to the tags/ directory in subversion.

      If this cannot be automated, then perhaps it should be possible to set the versions and scm urls etc after making the copy from the tag to the branch manually....

        Issue Links

          Activity

          Hide
          Wim Deblauwe added a comment -

          Isn't this already possible with -DupdateWorkingCopyVersions=false as stated in the documentation?

          Show
          Wim Deblauwe added a comment - Isn't this already possible with -DupdateWorkingCopyVersions=false as stated in the documentation ?
          Hide
          Reinhard Nägele added a comment -

          @Wim: I would have expected so, too, but even if updateWorkingCopyVersions is set to false, the working copy is committed (twice, actually, once with the changes for the branch, and once to revert those changes).

          Show
          Reinhard Nägele added a comment - @Wim: I would have expected so, too, but even if updateWorkingCopyVersions is set to false , the working copy is committed (twice, actually, once with the changes for the branch, and once to revert those changes).
          Hide
          Marcin Kuthan added a comment -

          To avoid commits into tag, you can use the following command:
          mvn release:branch -DbranchName=1.0.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true -DremoteTagging=false

          For me it should be a default behavior for release:branch. In my case the current development is made in trunk, released versions are tagged. If I need to fix released version, I create "patch" branch from the corresponding tag. E.g brach 1.0.x from tag 1.0. Make a fix and release 1.0.x branch as 1.0.1 (and the tag 1.0.1 is created as a result).

          So, branch is always created from a tag not from a trunk. And according to the SVN book, created tag must not be changed.

          Show
          Marcin Kuthan added a comment - To avoid commits into tag, you can use the following command: mvn release:branch -DbranchName=1.0.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true -DremoteTagging=false For me it should be a default behavior for release:branch. In my case the current development is made in trunk, released versions are tagged. If I need to fix released version, I create "patch" branch from the corresponding tag. E.g brach 1.0.x from tag 1.0. Make a fix and release 1.0.x branch as 1.0.1 (and the tag 1.0.1 is created as a result). So, branch is always created from a tag not from a trunk. And according to the SVN book, created tag must not be changed.
          Hide
          Frédéric Camblor added a comment -

          Problem with your workaround (-DsuppressCommitBeforeBranch=true -DremoteTagging=false) is we should manually update <version> and <scm> tags in branch poms.

          For me, it is not a convenient workaround.

          Show
          Frédéric Camblor added a comment - Problem with your workaround (-DsuppressCommitBeforeBranch=true -DremoteTagging=false) is we should manually update <version> and <scm> tags in branch poms. For me, it is not a convenient workaround.
          Hide
          Marcin Kuthan added a comment -

          Hi Frederic

          I just check again my repository and <version> and <scm> were updated in the branch pom. You can find an example there:
          http://code.google.com/p/m4enterprise/source/browse/branches/1.0.x/pom.xml?r=777

          The only disadvantage is that I have to execute release:branch in interactive mode. I didn't find a solution how to pass the next branch version as a property.

          Show
          Marcin Kuthan added a comment - Hi Frederic I just check again my repository and <version> and <scm> were updated in the branch pom. You can find an example there: http://code.google.com/p/m4enterprise/source/browse/branches/1.0.x/pom.xml?r=777 The only disadvantage is that I have to execute release:branch in interactive mode. I didn't find a solution how to pass the next branch version as a property.
          Hide
          Frédéric Camblor added a comment - - edited

          This is strange .. I ran it in batch mode with the following arguments :

          mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.1:branch -DautoVersionSubmodules=true -DtagBase=http://mysvnrepo/tags/ -Dtag=1.0test -DupdateBranchVersions=true -DreleaseVersion=1.0test-bugfixes -DbranchBase=http://mysvnrepo/branches/ -DbranchName=1.0test-bugfixes -DsuppressCommitBeforeBranch=true -DremoteTagging=false

          If you remove the "-DsuppressCommitBeforeBranch=true -DremoteTagging=false", your "next branch version" will take the -DreleaseVersion value.

          Show
          Frédéric Camblor added a comment - - edited This is strange .. I ran it in batch mode with the following arguments : mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.1:branch -DautoVersionSubmodules=true -DtagBase= http://mysvnrepo/tags/ -Dtag=1.0test -DupdateBranchVersions=true -DreleaseVersion=1.0test-bugfixes -DbranchBase= http://mysvnrepo/branches/ -DbranchName=1.0test-bugfixes -DsuppressCommitBeforeBranch=true -DremoteTagging=false If you remove the "-DsuppressCommitBeforeBranch=true -DremoteTagging=false", your "next branch version" will take the -DreleaseVersion value.

            People

            • Assignee:
              Unassigned
              Reporter:
              Alex B
            • Votes:
              12 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: