This section provides a step by step description to execute a release of the OpenEngSB. It is relevant for everyone marked in the OpenEngSB Team List as release manager because only they have the required rights to execute the following steps.
Every release of the OpenEngSB consists of the following parts: RELEASE.MAYOR.MINOR.TYPE. Every release of this type is available at Maven Central. Optionally SNAPSHOT is appended. Snapshot releases are available from the Sonatype Snapshot repository. This section explains what each modifier means and how it is used within the OpenEngSB.
SNAPSHOTS: Snapshots are always available from the latest build of the OpenEngSB. They are taken from the master branch automatically at each commit.
TYPE: Type could be MX, RCX or RELEASE, where X is a number. While RELEASE marks a final release, ready for use in your production environment, M and RC are typically not ready for production. M stands for Milestone release and is cut every two weeks to present the current state of the OpenEngSB and allow a coarse grained planning and roadmap for the OpenEngSB team. RC, release candidates, are handled differently. After everything is finished and the OpenEngSB teams think that the current work is ready for a release, we provide a release candidate and invite everyone to test the release. If there are any issues with the release we fix them and provide another release candidate. During this process no new features, but only bug fixes are handled. We continue this process as long as there are no new bug reports for a RC for two weeks. Then we re-release the latest release candidate as final release. This process only applies for RELEASE and MAYOR. MINOR is handled differently, as explained later on.
RELEASE is a increasing number used for mayor changes within the OpenEngSB architecture. In addition all methods and interfaces marked as deprecated are removed during such a release. It is also possible that a RELEASE does not enhance any mayor architectural concept but is only used to get rid of all the deprecated methods, generated during MAYOR releases.
MAYOR is the main feature development number of the OpenEngSB. Each release containing new features will be a MAYOR release. Nevertheless, between MAYOR releases architectural concepts are not removed but only set to deprecated. This means they only enhance functionality but try to not break with former releases.
MINOR releases are bug-fix releases. They do not include any new features but only fix bugs within the OpenEngSB. They have no release plan, but are simply cut after each bug-fix.
To visualize the explained process the following example. Assume we have released openengsb-1.0.0.RELEASE. Now we're working on openengsb-1.1.0.RELEASE. Therefore we start developing openengsb-1.1.0.M1 which will be released in two weeks. During the development of 1.1.0.M1 a bug occurs at openengsb-1.0.0.RELEASE. During the development the bug is fixed and openengsb-1.0.1.RELEASE is released. After 1.1.0.M1 we require three additional milestone releases to get feature releases. Six weeks after 1.1.0.M1 we'll release 1.1.0.RC1. From now on we continue to develop 1.2.0.M1 (or 2.0.0.M1, depending on the gravity of the changes) and wait for feedback on 1.1.0.RC1. Now a bug-report occurs for 1.0.1.RELEASE. We fix the bug, release 1.0.2.RELEASE with the fix. If it also affects 1.1.0.RC1, we fix the bug there too and release 1.1.0.RC2 (still working on 1.2.0.M1(!)). Now assume that some other bug reports are received for 1.0.0.RC2. We fix them and release 1.1.0.RC3. In the meantime we finished 1.2.0.M1 and start work on 1.2.0.M2. Now two weeks after the release of 1.1.0.RC3 without any new bug-reports we re-release 1.1.0.RC3 to 1.1.0.RELEASE (starting the game again from the beginning).
For the right rights to deploy to maven central and upload maven site to openengsb.org the following entries are required in your ~/.m2/settings.xml file:
<settings> <server> <id>sonatype-nexus-snapshots</id> <username>SONATYPE_USERNAME</username> <password>SONATYPE_PASSWORD</password> </server> <server> <id>sonatype-nexus-staging</id> <username>SONATYPE_USERNAME</username> <password>SONATYPE_PASSWORD</password> </server> <server> <id>OpenengsbWebServer</id> <username>OPENENGSB_SERVER_USERNAME</username> <password>OPENEGNSB_SERVER_PASSWORD</password> </server> <profiles> <profile> <id>milestone</id> <properties> <gpg.passphrase>GPG_PASSPHRASE</gpg.passphrase> </properties> </profile> <profile> <id>release</id> <properties> <gpg.passphrase>GPG_PASSPHRASE</gpg.passphrase> </properties> </profile> <profile> <id>final</id> <properties> <gpg.passphrase>GPG_PASSPHRASE</gpg.passphrase> </properties> </profile> </profiles> <settings>
All the usernames and passwords can be retrieved from someone marked as administrator in the OpenEngSB Team List.
In addition you have to have a GPG key for your mail address (the same you're using to commit to the OpenEngSB source repository which is uploaded to the MIT Key Server.
A word in front, how Jira is used for the OpenEngSB. Jira is used for bug tracking and release planning. ONLY each Milestone release has its own target. Release candidates and final releases are handled differently. Since we release RC and MINOR releases quite often its much too much administration work to keep JIRA up to date. For simplicity we provide for all release candidates of 1.0.0 only one 1.0.0.RCX release target. This is closed with the final release and replaced by 1.0.X.RELEASE target. This is replaced by 1.1.X.RELEASE. We don't know for the moment how we should handle older releases, but for the moment the OpenEngSB team simply do not have the man power to support older releases.
Ok, knowing that the release process is simple:
Performing a release is quite simple, because of the maven release plugin and some scripts. Simple follow these steps:
Post a message to the OpenEngSB twitter account with the following content:
openengsb-VERSION "NAME" released, closing XX issues (JIRA_RELEASE_REPORT_SHORT_URL). Try the new features now: http://openengsb.org
Finally the CHANGELOG.md file has to be updated. Therefore the following template with the correct version have to be copied in the current changelog file (the latest version always has the most "on-top" position in the text file):
openengsb-VERSION ------------------ ### Bug fixes * Bugfix ### Changed Components * New Projects * openengsb-core-taskbox * Removed Projects ### New Features & Changed Behaviour * Feature ### Depricated or remvoed Features * interface xyz