Release Plan and Actions
Prerequisites
Git Branches
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/)
JIRA Workflow
Each issue in JIRA has the following tags related to release process
- OpenNCP affects Version
- OpenNCP fix Version
- Affects Version
- Fix Version
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)
Notification of developers
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.
Synchronize the code
You have to pull the latest changes from the openncp modules
Create the release branch
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
Update version numbers in the development branch
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 pom.xml
file should be checked for NOT referencing -SNAPSHOT
versions.
Build the code
You have to double check that the project can be build successfully by this command
mvn clean test package
Finish the release branch
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
Push changes to code repository (Bitbucket)
Now you have to push the changes to Bitbucket in both branches (develop and master)
git push && git push --tags
Upload the release artifacts to JoinUp
There are some prerequisites for uploading releases to JoinUp:
- The component must have the
groupId
"eu.europa.ec.joinup.ecc" - The version number may not contain
-SNAPSHOT
postfixes
Furthermore, the OpenNCP project itself has some constraints:
- The
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
Notify the community on the Release
When the release has successfully concluded, send out emails to the developers and users mailing lists as well as to any other interested parties.
Update the openncp wiki
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
Update the JIRA Projects
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
Cleaning up
remove the local and the remote git branches:
git branch -d release/x.y.z git branch -r -d origin/release/x.y.z
Further Reading
Filter by label
There are no items with the selected labels at this time.