The Imixs Workflow Project consists of different subprojects components with different releases. The following section gives an overview how release management and versioning is handled in this project.
The release Number is separated into three digits.
2. 0. 1 | | |-- minor version | |-------- major version |-------------- main version
The main version number indicates the general main release of the imixs workflow. This number did not change very often. Typical this number will be increase when a gerenal redesign of the Imixs-Workflow-API is done.
You can not mix artifacts or components with different main versions!
The major version number is for general grouping the different artifacts and modules. Major versions are often started when a new technolgie is used or a main technology changed. For example switching from JEE5 to JEE6 can lead to an increase of the version number. As we use Maven as the general build and configuration framework major versions are typical reflected in dependencies. So for example the Imixs-Workflow-JEE-Impl depends on the Imixs-Workflow-JEE with the same major version.
You should not mix artifacts or components with different major versions.
The minor version number is for bug fixes, enhancements and feature requests. If possible artifacts and components with different minor versions should work togehter.</p>
Since version 2.1.0 the release management process is managed through the configuration and build framework Maven. Each subproject of the Imixs Workflow project contains a release management section in its pom.xml based on the maven-release-plugin. So the process of promoting a new release is a half automated process controlled by the Maven release plugin. See the brief instruction below.
The results are distributed to the follwoing repository locations with can be added to the settings.xml file of your maven setup:
This repository should be only used if snapshot releases are necessary for a specific build.
This repository contains all released artifacts from the imixs project. Commonly this repository is not necessary as all releases are published into the Maven central repository.
This is the default central repository used by maven without further configuration.
Each repository location can be added to the settings.xml configuration file from a local maven installation (typical located in ~/.m2/settings.xml)
General access to the snapshot releases and staging database:
The following brief instruction describes how to promote a new release based on the maven release plugin.
First of all the pom.xml of the subproject should fulfill all necesary informations to be deployed to the maven central repository Read details: https://docs.sonatype.com/display/NX/OSS+Repository+Hosting
Important informations are the scm tag and the maven-release-plugin configuration
The scm uris should point to the trunk folder of the subproject. E.g:
where XXXX is the name of the subproject
Next the maven-release-plugin should provide the configruation tags Base and mavenExecutorId. The tag Base should point to the tags folder. E.g.:
where XXXX is the name of the subproject
The distributionManagement section is necessary if the artefact should be released on sonatyp maven repository central. The section should include the snapshotRepository as also the repository location pointing to the sonatype staging repository:
The pom.xml is already configured for all promoted artifacts. So manual changes should not be necessary.
All existing snapshot dependencies should be remove from the pom.xml before promoting a new release!. For this reason the order of promoting the releases depends on the project dependencies.
After pom.xml is updated the project should be comited and updated with the svn repository. (Using Eclipse IDE it can be necessary to perform a -Team->update command also if no changes are displayed!
This step prepares a new tag and update the current snapshot realease. This can be used for all kinds of maven artefacts, even if the artefact is not released in a maven repository like the sonatype maven central repository. Some of the Imixs modules (e.g. imixs-script) are not part of the maven central repository. In this case only this step is necessary to create a new snapshot version.
After project settings (pom.xml) are verified and data is synchronized with svn use the mvn tool from a command line. Do not! use the eclipse maven plugin m2eclipse because interactive mode is not working reliable From a command line perform the following mvn goals:
mvn clean mvn release:prepare -Duser=xxxx -Dpassword=yyyy
This will tag the current snapshot and update the snapshot release. The user and password can be left by during release:prepare command if you provide these informations in you settings.xml file in the server section.
After step 4 was sucessfull and !only! if your artefact should be released into a maven repository (as for the most imixs artefacts) this step performs a release. Between prepare and perform you should check the svn tags/ folder of the subproject. It should be updated with the release. Also the pom.xml should be updated to the next snapshot version automatically. From a command line perform the following mvn goals:
For the release:perform phase you need a gpg key. See Making GPG keys.
If you were not prompted during release:perform to enter your gpg passphrase you can also use the following command to provide maven with your gpg password:
mvn release:perform -Darguments=-Dgpg.passphrase="xxxxxx"
The gpg key is typical stored in the users home directory (for Linux .~/gnugp) If a problem occurs first clean the release:
Next remove the generated new tag version
Uno changes to the pom.xml - in most cases the version should be replaced with the old snapshot version. After all you can repeat the steps explained before.
This step is only necessary if step 5 was performed. A imixs artefact is typically release during the prepare phase into the sonatype maven central repository. You need finally check the http://oss.sonatype.org staging repository and 'close' and 'release' your artefact manually using the sonatype frontend.
The Release should be published during the next 6 hours