77

What is the best way to change version of Maven project, to release this version and then return back to *-SNAPSHOT development.

Currently I'm doing following:

  • retrieve current version (most likely with SNAPSHOT) from pom.xml
  • increment version (mvn -DnewVersion=<something> versions:set), respecting rules described in the question Maven artifact version for patches
  • mvn:install to sent to repo
  • renaming version once again adding SNAPSHOT postfix.
  • committing changes (using some version control system)

I have a strong feeling I'm doing something wrong and/or inefficient.

Community
  • 1
  • 1
shabunc
  • 23,119
  • 19
  • 77
  • 102
  • 1
    Generally nighty build having next-release-number-SNAPSHOT. So while releasing just remove -SNAPSHOT & release it. – Nikhil Mar 25 '17 at 01:36

2 Answers2

87

You should use the maven-release-plugin to release your artifacts. Than automatically all your versions will be incremented by the release-plugin. The exception might be if you are going from 1.0.3-SNAPSHOT to 1.1.0-SNAPSHOT . The timeline for developing with Maven is:

1.0.0-SNAPSHOT
1.0.0
1.0.1-SNAPSHOT
1.0.1
1.0.2-SNAPSHOT
1.0.2
..

To go for the step from a SNAPSHOT to a release version you should use the maven release plugin you can release an artifact simply by using:

First step:

mvn release:prepare

The final step:

mvn release:perform

If you would like to accept the defaults you can simply add -B like:

mvn -B release:prepare

or you can combine those steps into a single one:

mvn -B release:prepare release:perform

The above can also be used from within a CI solution.

Using mvn install is only intended to install the artifacts into your local repository. If you are working with a real one like a repository manager (which i can recommend) you have to use:

mvn deploy

One requirement for using the release plugin is to configure the scm area in your pom (i hope you are using a version control?).

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • You may even omit the z position since e.g. 1.1 and 1.1.0 are equal. This is what I do and all maven plugins do. Moreover, a sole `release:peform` will fail because you did not provide `-DscmUrl=...`. – Michael-O Mar 05 '12 at 19:17
  • 2
    @Michael-O why are you specifying the SCM URL on the command line? I suspect khmarbaise has provided it via the POM setting – earcam Aug 21 '12 at 12:46
  • @earcam, because the the plugin needs to know from there the release has to be built. The scm element contains not trunk in the default checkout. – Michael-O Aug 21 '12 at 13:32
  • Hi @Michael-O, you probably should be using .../trunk in the developerConnection see http://maven.apache.org/scm/plugins/usage.html and furthermore it's specifying trunk here http://maven.apache.org/guides/mini/guide-releasing.html - I'm using Git so not really an issue. The whole release:prepare/release:perform works for me without specifying any further parameters – earcam Aug 22 '12 at 14:35
  • Re-read my first comment, I crearly indicated why and when you need to provide the SCM URL. – Michael-O Aug 22 '12 at 19:03
  • @Michael-O a bit late but still - please re-read my first comment too, we have numerous projects working fine simply using the scm definition and all the documentation backs that up. If you're going to refute this, please cite some evidence. – earcam Dec 05 '12 at 12:07
  • Please recite the prominent part of the comment. I cannot really track what you want. If you are referring to the scmUrl. You have to supply that uf you perform first prepare and then perform in two separate steps. – Michael-O Dec 05 '12 at 13:40
  • @Michael-O, quote: "release:peform will fail because you did not provide -DscmUrl=..." - It will not if you specify all pertinent information in the SCM tags of the POM. I issue `mvn release:prepare` and `mvn release:perform` several times a fortnight without any further parameters. Anyway believe what you will, it was a minor correction that you seem hellbent of refusing, so be it. Go well, in peace. – earcam Jan 06 '13 at 21:23
  • @earcam, well I haven't used those goals seperately for years. Always in tandem and they worked fine. – Michael-O Jan 07 '13 at 09:18
  • 1
    Bump. release:prepare actually adds an scm path in the TAG when it is committed. When performing release:perform, the latest tag will be built which magically has the scm path set. That is why you don't have to specify any path in your trunk project. – Johan Tidén Sep 09 '13 at 11:24
  • Can you confirm that the _timeline for developing_ is from `1.0.0-SNAPSHOT` to `1.0.0` and not from `1.0-SNAPSHOT` to `1.0.0`? – vault Jul 16 '19 at 12:45
  • 2
    I can confirm that. If you like to use `1.0-SNAPSHOT` than the release would be `1.0`...and not `1.0.0`... – khmarbaise Jul 16 '19 at 12:55
  • Best practices? Consider : https://axelfontaine.com/blog/dead-burried.html too – Christoph Henrici Feb 22 '23 at 08:47
5

If you want more control over the release phase, the maven-release-plugin (mrp) will not help you much.

In that case I have modified versions-maven-plugin to be able to increment version and also to add / remove SNAPSHOT suffix.

Thanks to these new features you are able to write script that do the same thing as mrp, but you have full control over each step.

For example, mrp commits changed version before it actually tries to build it. If the build fails, you have to revert that commit or, in case of SVN, you have to do another revert-commit.

Note: I am not the original author of the increment function. I have adopted it from autoincrement-versions-maven-plugin, as stated on github page.

Petr Újezdský
  • 1,233
  • 12
  • 13
  • 1
    I have created a pull request on official `versions-maven-plugin` github page, hopefully they integrate it https://github.com/mojohaus/versions-maven-plugin/pull/23 – Petr Újezdský Jan 08 '16 at 17:05
  • 1
    What if I don't want maven screwing around with SCM? For example, with GitHub actions I can fire off some CI with the TAG action but this directly conflicts with mavens release process... – Alex Barker May 19 '20 at 23:58
  • Well, a lot has changed in the last 5 years. If they did not update the plugin to be more usable (however they didn't even bother with my pull-request above), I would consider using different method. Do not know which one though. – Petr Újezdský May 22 '20 at 10:04
  • I ended up asking [another SO](https://stackoverflow.com/questions/61926797/maven-release-without-tagging-or-compiling/61927016#61927016) question about this as I was unable to find a suitable solution. Turns out it can be done with the version plugin. – Alex Barker May 22 '20 at 15:35
  • My solution above also uses `versions-maven-plugin`. It just adds another goals to be even more flexible. Though it is a bit outdated now I presume. – Petr Újezdský May 27 '20 at 19:21