Kura Release Engineering

Introduction

On the release-x.y.z branch:

1. Create meta information on release branch
   1. Git tag added to kura.properties (DW: What is the name of the property?)
   2. Optional: Job name and build number added to kura.properties. It means that a release candidate installer is identified by the tuple (tag, job name, build number). (DW: What is the name of the property?)
2. Create KURA_X.Y.Z_RCN tag
3. Build on Hudson/Jenkins a release candidate against the RC tag
   1. Make build artifacts (installers, add-ons, Javadoc) available for QA
   2. Do not deploy Maven artifacts to Nexus as it does not allow overwriting artifacts
4. Start or continue QA based on the availability of a new RC
   1. When fixes are available, QA team can ask for a new RC and continue (not restart) the QA
   2. No RC binaries can be released without an (at least partial) assessment by the QA team
5. QA done
   1. Deploy same Maven artifacts of the last validated RC to Nexus. If something fails, e.g. deploying to Nexus, goto...?
   2. Publish same installers of the last RC validated by the QA team on the Kura web site
   3. Publish same Javadoc of the last RC validated by the QA team
   4. Publish same add-ons of the last RC validated by the QA team on the Eclipse Markeplace
   5. Update the Kura web site
6. Post release
   1. Create KURA_X.Y.Z_RELEASE tag. It must coincide with the tag of the last validated RC
   2. Merge release branch on the develop branch