Create a release in a standardized way including the following steps:
-
verify the current project (no local changes, etc.)
-
warn if
«version»-SNAPSHOT
dependencies are used -
determine
«version»
(if currently«version»-SNAPSHOT
) and print out release information. -
ask user for confirmation
-
bump release to
«version»
in build configuration (e.g.pom.xml
files) -
commit the change
-
create annotated tag for your release as
release/«version»
-
invoke deployment on build-system
-
set next version as
(«version»+1)-SNAPSHOT
in build configuration (e.g.pom.xml
files) -
commit the change
-
push your changes
devon java
Argument(s) | Meaning |
---|---|
|
any optional argument will directly be passed to the actual command to build the deployment |
This release
commandlet utilizes the build commandlet to support multiple build-tools such as maven, gradle, or npm. Each of those commandlets should respect the variable «TOOL»_RELEASE_OPTS
to customize the parameters for the release build.
So e.g. if a pom.xml
is detected, maven will be used. In this example the variable MVN_RELEASE_OPTS
is used that defaults to clean deploy -Dchangelist= -Pdeploy
.
If you provide a specific argument this will be passed additionally.
So if you invoke the command devon release -P myProfile
, the above step invoke deployment on build-system
would technically call this:
mvn clean deploy -Dchangelist= -Pdeploy -P myProfile
Please also note that it is very tricky to determine and modify the version of a project in a fully generic way.
Even though we try our best to support different scenarios, we can not ensure this is working for edge-cases.
Therefore, we strongly encourage to follow best practices such as ci-friendly maven.
Further, sticking to the defaults and follow the devonfw standard to name the profile for custom goals in deployment simply deploy
is recommended.