-
Notifications
You must be signed in to change notification settings - Fork 145
Expand file tree
/
Copy pathprepare-release.apt.vm
More file actions
144 lines (105 loc) · 4.7 KB
/
prepare-release.apt.vm
File metadata and controls
144 lines (105 loc) · 4.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
------
Prepare a Release
------
Carlos Sanchez <carlos@apache.org>
Brett Porter <brett@apache.org>
John Tolentino <jtolentino@apache.org>
Dennis Lundberg <dennisl@apache.org>
------
2010-01-03
------
~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements. See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership. The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License. You may obtain a copy of the License at
~~
~~ http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied. See the License for the
~~ specific language governing permissions and limitations
~~ under the License.
Prepare a Release
Preparing a release goes through the following release phases {{{../../maven-release-manager/#prepare}by default}}:
* Check that there are no uncommitted changes in the sources
* Check that there are no SNAPSHOT dependencies
* Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
* Transform the SCM information in the POM to include the final destination of the tag
* Run the project tests against the modified POMs to confirm everything is in working order
* Commit the modified POMs
* Tag the code in the SCM with a version name (this will be prompted for)
* Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
* Commit the modified POMs
[]
To prepare a release execute this command:
-------
mvn release:prepare
-------
<<Note:>> If an error occurs, or the process is cancelled, then running this command again will pick up from where the
last one left off.
If you wish to start again, use:
-------
mvn release:prepare -Dresume=false
-------
Alternatively, you can use:
-------
mvn release:clean release:prepare
-------
<<Note:>> If any changes have been made to your source files they might need to be reverted before you restart the
prepare process. You can use <<<release:rollback>>> to make the plugin do it for you.
* Multi-module projects
You will be prompted for the version number for each module of the project.
If you prefer that every module gets the same version as the parent POM,
you can set the option <<<autoVersionSubmodules>>> to <<<true>>>. Now you will
be asked only once for the release version and the next development version.
* Generating release POMs
It is possible to generate a <<<release-pom.xml>>> file for each project that contains the fully resolved project used
at release time as a record for later. As of the 2.0 release, this requires calling an alternate goal:
---
mvn release:prepare-with-pom
---
This goal is equivalent to the <<<release:prepare>>> goal, except that it requires a previous build of the project to
exist to properly populate the <<<release-pom.xml>>> files.
* Overriding the default tag name format
By default, if you do not specify a tag name, a default tag name of <<<version>>> will be
suggested (and if running non-interactively used).
You can specify the exact tag name to use from the command line by passing the <<<tag>>> property, but if you
want to have the tag name generated, but just change the default pattern, you can use the <<<tagNameFormat>>>
configuration option.
For example to have the tag name default to the version number prefixed with a <<<v>>> you could configure
your pom like so:
+-----
<project>
[...]
<build>
[...]
<plugins>
[...]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>${project.version}</version>
<configuration>
<tagNameFormat>v@{project.version}</tagNameFormat>
</configuration>
</plugin>
[...]
</plugins>
[...]
</build>
[...]
</project>
+-----
The tagNameFormat uses <<<@\{>>> and <<<}>>> as delimiters in order to ensure that the default Maven property
interpolation does not substitute the values before the version transformation has taken place.
The following properties are supported:
* <<<project.groupId>>> which corresponds to the project's groupId.
* <<<project.artifactId>>> which corresponds to the project's artifactId.
* <<<project.version>>> which corresponds to the project's release version.
[]
The <<<project.>>> prefix is optional and may be omitted.