Here's a quick summary of being Platform release manager (from Darius Jazayeri):
If you need GitHub/JIRA privileges, Bamboo account, open a ticket to request it.
Prior to any release make an initial decision and post to Talk on what will be included in the release.
In most cases, this should be fairly clear from the Road Map; however, some projects may be a little behind schedule and a decision made whether they can be properly resourced/sped up to meet the release timeline or need to be bumped to a later release. You do not need to do all of the work of making these decision (the community should do that), but you should help ensure that the discussion occurs and you are the final arbiter for these decisions.
Features that have been committed, but are not going to be in the release need to be removed from the code.
If necessary, hold a Release Prioritization Meeting to prioritize tickets and finalize, which will be included in the release.
Before an alpha release, all New Feature tickets should either be Closed or at least in a Post Commit state. The same goes for Blocker tickets.
An alpha is a feature-complete release, but is not yet verified to be bug free.
An alpha version is indicated by appending "-alpha" to the version e.g. "2.2.0-alpha".
A release is ready to go from alpha to beta when preliminary testing has been completed and any bugs squashed (a minimum of rudimentary testing, ideally as many steps in the complete testing list as possible). If large bugs are found and squashed, "alpha.2", "alpha.3", etc. may be released to aid testers as needed.
Releasing additional alpha releases is up to the release manager. Going from alpha to beta does not require community discussion and is up to the release manager, but should be done only after the release manager has confirmed with testers that all known bugs have been squashed.
A beta is a release that is ready to be tested by a larger group of people. Obvious bugs found in the alpha have been found and fixed.
A beta version is indicated by appending "-beta" to the version e.g. "2.2.0-beta".
Be sure to examine all outstanding tickets for the release milestone. By the time a beta release is being considered, all of the tickets assigned to the release milestone should have a clear trajectory (either be moved to a later release or have plans in place to address the issue by the full release).
Going from beta to a release candidate or full release requires that testing have been completed and the system formally exercised by at least one (ideally two or more) implementation.
The decision to go from beta to release candidate or final release should be led by the release manager but agreed by the developer community (via mailing list or dev call).
A release candidate is only needed when non-trivial changes were required during the beta phase. If the beta release was tested and no significant changes were needed, then you can proceed directly to a full release.
A release candidate version is indicated by appending "-rc" to the version e.g. "2.2.0-rc".
Going from release candidate to full release requires that testing have been completed and the system formally exercised by at least two or more implementations. The decision to go from release candidate to final release should be led by the release manager but agreed by the developer community (via Talk).
A true "Release" is deemed tested and worthy of production environments.
Review all existing tickets. Be certain that all tickets assigned to this release milestone have been addressed and that there aren't any straggling tickets for this milestone or previous milestones.
A maintenance release contains bug fixes and security patches for use between major releases, e.g., from 1.8.0 to 1.8.1. There is no branch to create. You just pick up where you left off in the current minor version series release branch.
There's a number of steps to follow when doing an alpha/beta/rc/final/maintenance release. Please also refer to instructions for different types of releases (alpha/beta/rc/final/maintenance), which you can find in the next paragraphs.
If it is not a maintenance release, the release process should start from creating a maintenance branch.
Steps to follow for all releases:
Download the latest CIEL for OpenMRS 1.9.x (use 1.9.x regardless of the release version) as described here. Upload the version to our maven repository to be used in standalone by running (adjust the version and the file parameters to match the downloaded version of CIEL):
In the file listing page on Sourceforge, open the recently released version, click the info "i" button next to the standalone to expand the details of the uploaded ZIP file. For "Download Button", type "OpenMRS Platform 2.0.5 Standalone". Under "Default Download For:" check all the option boxes. Click "Save" to save the settings.
Create a help desk case with https://help.openmrs.org/customer/portal/emails/new at a minimum of one working day prior to the scheduled release providing download links. DO NOT mark Impact as anything other than "Routine."
Use the following template for description (replace 2.0.5 with the correct version, the release date & time and the JIRA url, which you can determine from https://issues.openmrs.org/browse/TRUNK/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel):
mvn release:prepare You may also get an error message in validating the generated JavaDoc files, which you can resolve by adding
-Darguments="-Dmaven.javadoc.skip=true"to skip the validation process. However this does not work with Java 8
mvn release:prepareyou may want to rollback the release process to fix them, then use
mvn release:rollback. However this has to be followed by the manual deletion of the tag that was created in the local git environment.
mvn clean deploy --batch-modeYou may get an error message like this: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project openmrs: Failed to deploy artifacts: Could not transfer artifact ............ Failed to transfer file ......... Return code is: 401 -> [Help 1]. Solving this requires you to have a nexus repository account, under the openmrs-repo-releases section, in your maven settings.xml file which should be in your MAVEN_HOME folder. If this file does not already exist, you need to create one. See the example maven settings.xml file attached: settings-example-mvnrepo.xml.
mvn clean deploy --batch-mode You may also get an error message like: Failed to transfer file: ......... Return code is: 400 The reason is that the Maven nexus release repo does not allow redeployment by default. To enable that, you could logon nexus and select the release repo, then change the configuration to allow redeployment there. But be aware that any projects using the release artifact will ONLY download the artifact once and thus the artifact you redeployed may not be able to be consumed by the projects, which may cause a lot of troubles. The solution is to manually remove the cached release artifact under .m2/repository so that Maven can download the new one. Because of the disadvantage for the above approach, i just logged onto the nexus repository and manually deleted the successfully deployed artifacts. Then i was able to deploy again.
mvn clean deploy --batch-mode You may also get an error message like: [ERROR] Java heap space -> [Help 1]. To solve this, increase the memory for maven. On my mac, i just typed this on the same shell terminal where i was deploying from: export MAVEN_OPTS="-Xmx512m -Xms128m -XX:MaxPermSize=512m"
When you are deploying a module to nexus repository using: mvn clean deploy command You may get an error message like [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project...Return code is: 401, ReasonPhrase:Unauthorized. To solve this you need to add a server for the module repo by adding the following with nexus repository credentials to the list of servers in the file /M2_HOME/settings.xml .