Release plan and actions assumes that all OpenNCP modules are being developed in git branch named "develop" and the "master" branch is being kept in sync with latest releases. It is recommended also to enable in your development environment the git flow extensions (http://danielkummer.github.io/git-flow-cheatsheet/)
Each issue in JIRA has the following tags related to release process
When an issue is opened is tagged with the "affects" related tags (OpenNCP affects Version and Affects Version).
Each OpenNCP version is a list of components that have their version numbers. This relation is being hold in the Version Management page. So the previous tags relate to these 2 types of versions (openncp version and component version)
Notify the developers through the official mailing list that a release branch is about to be created and if needed, give them time to merge their features to develop in order to include them in the upcoming release.
You have to pull the latest changes from the openncp modules
Creating a release branch amounts to:
git flow release start x.y.z This command will create a local release branch named "release/x.y.z" |
where x.y.z
is the release version. Each release candidate is tagged using git tag -s
vx.y.z-rc1
-m"Release candidate rc1 of the x.y.z release
". A new release candidate may be comprised of just a single commit, but may also be a collection of commits that together comprises the resolution of a bug. A new git tag is created for each release candidate, and the pom.xml
files in the affected individual projects should be updated such that proper artifacts can be identified.
The x.y.z
part of the version name of the release branch is kept unchanged, and when the final release candidate is verified
The pom.xml
files in all components must be updated to the next target version and post-fixed by removing SNAPSHOT extension
This can be done with the maven command
mvn versions:set -DnewVersion=X.Y.Z |
The Release Process
Because of their interdependencies, the components must be released in reverse dependency order. That means that the "bottom" dependencies - which is currently epsos-configurationmanager
and epsos-util
- must be released first, so that the other components whose SNAPSHOT versions pointed to the new releases, are resolved correctly. A complete dependency diagram is viewable at the Version Management wiki page.
Before starting with the actual release steps, the |
You have to double check that the project can be build successfully by this command
mvn clean test package |
Now you have to finish the release in git flow by typing
git flow release finish x.y.z |
This command will do the following
- Release branch will be merged into 'master'
- The release will be tagged 'x.y.z'
- Release branch will be back-merged into 'develop'
- Release branch 'release/x.y.z' will be deleted
Now you have to push the changes to Bitbucket in both branches (develop and master)
git push && git push --tags |
There are some prerequisites for uploading releases to JoinUp:
groupId
"eu.europa.ec.joinup.ecc"-SNAPSHOT
postfixesFurthermore, the OpenNCP project itself has some constraints:
artifactId
must match the regular expression ^epsos-(?:[a-z]+[-_]?)+$
For each project that is to be deployed to joinup, go into the directory and perform the following command
mvn deploy -f path/to/pom.xml |
When the release has successfully concluded, send out emails to the developers and users mailing lists as well as to any other interested parties.
Each release must be accompanied by a release notes and change notes wiki page. See this as an example: 1.1.0 Release Changelog and Notes
To create a new release notes page, go to the previous release notes page and copy that one. Fix the title, the components affected and the JIRA macro.
Furthermore, the Version Management wiki page must be edited to reflect the new versions in master and develop
Each component has a corresponding JIRA project, which has a version corresponding to this release. This version must be marked as 'released' and any pending (non-resolved) issues must be moved to the next release version. All issues that have been resolved in this release must be update with the "Fix OpenNCP Version" to point to this release. Also they have to be tagged with "Fix Version" with the component version
remove the local and the remote git branches:
git branch -d release/x.y.z git branch -r -d origin/release/x.y.z |
|