Create a release in a standardized way including the following steps:
-
verify the current project (no local changes, etc.)
-
warn if
«version»-SNAPSHOTdependencies 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.xmlfiles) -
commit the change
-
create annotated tag for your release as
release/«version» -
invoke deployment on build-system
-
set next version as
(«version»+1)-SNAPSHOTin build configuration (e.g.pom.xmlfiles) -
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 mutliple 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 myProfilePlease 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.