You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@plc4x.apache.org by cd...@apache.org on 2019/10/21 16:54:55 UTC

[plc4x] 02/02: Cleanup some documentation

This is an automated email from the ASF dual-hosted git repository.

cdutz pushed a commit to branch rel/0.5
in repository https://gitbox.apache.org/repos/asf/plc4x.git

commit 5e23a6d53ca5127487324087586d545a45ad09fc
Author: Christofer Dutz <ch...@c-ware.de>
AuthorDate: Mon Oct 21 18:54:47 2019 +0200

    Cleanup some documentation
---
 src/site/asciidoc/developers/release.adoc | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/src/site/asciidoc/developers/release.adoc b/src/site/asciidoc/developers/release.adoc
index c697204..585bc5e 100644
--- a/src/site/asciidoc/developers/release.adoc
+++ b/src/site/asciidoc/developers/release.adoc
@@ -173,25 +173,17 @@ In order to prepare a release-candidate, the first step is switching to the corr
 
 After that, the following command will to all preparation steps for the release:
 
-   mvn release:prepare -P with-cpp,with-dotnet,with-java,with-proxies,with-python,with-sandbox -DautoVersionSubmodules=true
+   mvn release:prepare -P with-cpp,with-dotnet,with-java,with-proxies,with-python,with-sandbox,with-boost,with-logstash -DautoVersionSubmodules=true
 
-(The `-P with-cpp,with-dotnet,with-java,with-proxies,with-python,with-sandbox` tells maven to activate the all profiles that partition the build and makes sure the versions of all modules are updated as part of the release)
+(The `-P with-cpp,with-dotnet,with-java,with-proxies,with-python,with-sandbox,with-boost,with-logstash` tells maven to activate the all profiles that partition the build and makes sure the versions of all modules are updated as part of the release)
 In general the plugin will now ask you 3 questions:
 
 1. The version we want to release as (It will suggest the version you get by omitting the `-SNAPSHOT` suffix)
 2. The name of the tag the release commit will be tagged with in the SCM (Name it `release/{release-version}` (`release/{current-full-version}` in our case)
-3. The next development version (The version present in the pom after the release) (`{current-next-minor-version}` in our case)
+3. The next development version (The version present in the pom after the release) (`{current-next-bugfix-version}` in our case)
 
 Usually for 1 and 3 the defaults are just fine, make sure the tag name is correct as this usually is different.
 
-We currently have a dependency to a SNAPSHOT dependency in the sandbox module.
-The release plugin will complain about this and we will not be able to release this way.
-As this in the sandbox module, we can force the plugin to continue by appending:
-
-   -DignoreSnapshots=true
-
-However it is important to check that nowhere else SNAPSHOT versions are referenced.
-
 What the plugin now does, is automatically execute the following operations:
 
 1. Check we aren't referencing any `SNAPSHOT` dependencies.