All OpenMRS ID accounts have been reset.

Read more and change your password before signing in.
Icon

EXTENDED: OMRS14 Proposals due 30 April! Read more and submit a proposal at OpenMRS Talk.

Skip to end of metadata
Go to start of metadata
On this page:

Release Planning

How do things make it into a specific release or on the Technical Road Map  See the page on Technical Road Map Planning.

Being the Release Manager

The role of the Release Manager in OpenMRS is to handle the process of getting code stabilized, packaged and released to the general public. If we were building planes, the RM would be the guy looking at the construction checklists, painting the airline logo on the fuselage, and delivering the finished unit to the customer.

As such, there is no real development associated with being an RM. All the work you have to do is non-coding: coordinating people, centralizing information, and being the public voice announcing new stable releases. A lot of the tasks that the RM has to do are repetitive, and not automated either because nobody has broken down and written the tools yet, or because the tasks require human validation that makes automation a little superfluous.

So, if you are the Release Manager. What do you need to do?

Prerequisites:

  • An OpenMRS ID (duh)
  • A SourceForge account
  • ...

Here's a quick summary of being release manager (from Darius Jazayeri):

  1. Pick some tickets and kick others out of the release
  2. Keep an eye on those tickets, looking for unassigned & those assigned with no movement, occasionally pinging folks to see what's needed to move things along.
  3. For tickets awaiting to be reviewed and whose reviews are small, you can go ahead and review them yourself.
  4. Pull together the release (an hour or two of time)
    1. Preliminary testing
    2. Releasing an alpha release
  5. Oversee subsequent releases as described on the Release Process page.

How does OpenMRS choose what goes into a release?

For the most part this is decided by the leadership group.  Larger tasks are decided upon way ahead of time and put onto the Technical Road Map. The RM will really be participating in the Release Prioritization Meeting to pick out a lot of the smaller tickets that are able to be completed on time.

How much time does it take to be a release manager?

The time requirement varies from week to week, but shouldn't be more than 4 hours.  The major time investments come when doing the final testing and writing up the wiki pages. (like these: Release Notes 1.5.0).  But usually you're just checking in with ticket owners to make sure they're going to hit the deadline.

Am I in it alone?

No, we do pair RM here at OpenMRS.  The two RMs coordinate on tasks, reporting, etc.

Prior to Alpha Release

Prior to any release.

  1. Make an initial decision on what will be included on 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.

Hold a Release Prioritization Meeting to prioritize tickets and finalize which will be included in the release as well as ten minor tickets that will be included in the release.

  1. Decide on what module(s) will be bundled with the release.
  2. Check those modules JIRA projects for any outstanding tickets and potentially hold prioritization meeting for them as well

Core modules are required; however, bundled modules are optional with any release. In most cases, you can simply continue with the bundled modules from the last release; however, there may be new modules that are candidates for bundling or existing bundled modules that should come out. Again, this should be a community decision, but your job is to ensure that the discussion takes place and to serve as the final arbiter for any dispute(s).

  1. Announce the upcoming Unsupported Releases (EOL) for the line of releases two back. (e.g. if you're releasing 1.7, announce EOL for 1.4.x)

Note:

Icon
  • 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.
  • You can perform the branching and releasing process either manually or by using the maven-release-plugin.
  • You will need to have an OpenMRS ID to create the required wiki pages and an OpenMRS Word Press account to create the release blog post. If you need an account, open a ticket to request it.
  • You will also need a SourceForge account to be able to upload files. This account needs to be associated with the OpenMRS project. If it isn't, open a ticket to request the association.

Alpha Release

An alpha is a feature-complete release but is not yet verified to be bug free.

  1. There are two ways of branching for the release:
    1. Option 1: Automatic Maven way:
      1. Run mvn release:branch -DbranchName=1.8.x -Dusername=<scm-username> -Dpassword=<scm-password>
        • The username/password can be omitted if the subversion credentials are cached.
      2. At the interactive prompts, enter the following:
        New trunk development version: 1.9.0-SNAPHOT
        • To run in non-interactive mode, include the following with the release:branch command:
          -B -DdevelopmentVersion=1.9.0-SNAPSHOT
      3. If a failure occurs, the local changes can be reverted by running mvn release:clean
    2. Option 2: Manually:
      1. Create the branch used for the life of this release: e.g. 1.8.x.
      2. In trunk, change the values of the version tags in the pom files to be "1", "9", "0", and modifier of "SNAPSHOT". Commit.
      3. In the branch, update the scm urls in the pom to point to the new branch's location in the repository.
  2. Checkout the maintenance branch e.g 1.8.x
  3. Add or Update any bundled modules you wish to include before creating the tag and then Commit the changes.
  4. Run mvn clean install, verify all tests are passed and no changes to be committed.
  5. Do some last minute rudimentary testing. See Testing Releases.
  6. Announce on the developer list that you are about to tag a release and make sure that everyone is prepared.
  7. There are two ways of tagging the release:
    1. Option 1: Automatic Maven way:
      1. Run mvn release:prepare -Dusername=<scm-username> -Dpassword=<scm-password>
        • The username/password can be omitted if the subversion credentials are cached.
      2. At the interactive prompts, enter the following:
        Release version: 1.8.0-alpha
        Tag name: 1.8.0-alpha
        Development version: 1.8.0-SNAPSHOT
        • To run in non-interactive mode, include the following with the release:prepare command:
          -B -DreleaseVersion=1.8.0-alpha -Dtag=1.8.0-alpha -DdevelopmentVersion=1.8.0-SNAPSHOT
      3. If a failure occurs, the release changes can be reverted by running mvn release:rollback, but committed tags will need be to removed manually.
        • If no changes have been committed to subversion, the release can also be cleaned up using mvn release:clean
    2. Option 2: Manually:
      1. Change the values of the version tags in the pom files to be '1.8.0-alpha' the values of the scm URLs in the pom files to point to the new tag's location in the repository.
      2. Tag the branch with the name 1.8.0-alpha. (Using the SVN Repository View in subclipse: right-click --> SVN Branch/tag). Remember to add any bundled modules you wish to include before creating the tag.
      3. In the 1.8.x branch, change the values of the version tags in the pom files back to "1", "8", "0", and modifier of "SNAPSHOT" e.g 1.8.0-SNAPSHOT, change the values of the scm URLs in the pom files to point to the 1.8.x branch's location in the repository. Commit the changes.
  8. Check out the '1.8.0-alpha' tag and use it to build the archives with the maven 'package' goal and upload them to  OpenMRS Download Files
  9. Deploy the files to maven repository with the command mvn clean deploy --batch-mode
  10. Create the Standalone. See the Standalone readme.txt file for how to build and package the standalone. Before you build the standalone please include the latest version of the CIEL dictionary by updating mvp-data.sql. After the standalone is packaged, add bundled modules to the war in openmrs-standalone/tomcat/webapps/openmrs-standalone.war/WEB-INF/bundledModules.
  11. Create the alpha release notes page at Release/Prelease Notes using all commits to trunk since the last release. e.g. Release Notes 1.8.0 Alpha
  12. Create the read me files, you can pick the ones from the prior releases at OpenMRS Download Files on sourceforge and edit it accordingly by updating the versions.
  13. Create a homepage news item by posting to blog.openmrs.org, you can use word press to create the blog.
  14. Send an announcement to the implementers and developers mailing lists.
  15. Send an announcement to the module author mailing list about any new features that effect modules (API changes, new features) and encouraging module authors to test their modules against the new version of OpenMRS.

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.

Beta Releases

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.

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).

  1. Checkout the maintenance branch e.g 1.8.x
  2. Add or Update any bundled modules you wish to include before creating the tag and then Commit the changes.
  3. Run mvn clean install, verify all tests are passed and no changes to be committed.
  4. Do some last minute rudimentary testing. See Testing Releases
  5. There are two ways of tagging the release:
    1. Option 1: Automatic Maven way:
      1. Run mvn release:prepare -Dusername=<scm-username> -Dpassword=<scm-password>
        • The username/password can be omitted if the subversion credentials are cached.
      2. At the interactive prompts, enter the following:
        Release version: 1.8.0-beta
        Tag name: 1.8.0-beta
        Development version: 1.8.0-SNAPSHOT
        • To run in non-interactive mode, include the following with the release:prepare command:
          -B -DreleaseVersion=1.8.0-beta -Dtag=1.8.0-beta -DdevelopmentVersion=1.8.0-SNAPSHOT
      3. If a failure occurs, the release changes can be reverted by running mvn release:rollback, but committed tags will need be to removed manually.
        • If no changes have been committed to subversion, the release can also be cleaned up using mvn release:clean
    2. Option 2: Manually:
      1. Change the values of the version tags in the pom files to be '1.8.0-beta' the values of the scm URLs in the pom files to point to the new tag's location in the repository.
      2. Tag the branch with the name 1.8.0-beta. (Using the SVN Repository View in subclipse: right-click --> SVN Branch/tag). Remember to add any bundled modules you wish to include before creating the tag.
      3. In the 1.8.x branch, change the values of the version tags in the pom files back to "1", "8", "0", and modifier of "SNAPSHOT" e.g 1.8.0-SNAPSHOT, change the values of the scm URLs in the pom files to point to the 1.8.x branch's location in the repository. Commit the changes.
  6. Check out the '1.8.0-beta' tag and use it to build the archives with the maven 'package' goal and upload them to  OpenMRS Download Files
  7. Deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Create the Standalone. See the Standalone readme.txt file for how to build and package the standalone. Before you build the standalone please include the latest version of the CIEL dictionary by updating mvp-data.sql. After the standalone is packaged, add bundled modules to the war in openmrs-standalone/tomcat/webapps/openmrs-standalone.war/WEB-INF/bundledModules.
  9. Create the beta release notes page under Prereleases using all commits to trunk since the last release. e.g. Release Notes 1.8.0
  10. Create the read me files, you can pick the ones from the prior releases at OpenMRS Download Files on Sourceforge and edit it accordingly by updating the versions.
  11. Create a homepage news item by posting to OpenMRS.org, you can use WordPress to create the blog.
  12. Send an announcement to the implementers and developers mailing lists.

Testing a Beta Release

  • Rudimentary testing should have already been done when creating the beta version.
  • Recruit volunteers to help test the beta version, including at least one implementation. Ideally, testers would run through all items in the list of application-level tests "More Complete Testing Process" on the Testing Releases page. It may help to copy this list to a shared document (e.g., Google doc or Wave) and have testers strike out tests that have been completed.
  • Consider adding to the More Complete Testing Process list to cover any bugs discovered at the application level (that may not be completely covered by unit testing) which are not currently included in that list.

Going from beta to a release candidate or full release requires that testing scripts 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).

Release Candidates

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.

  1. Checkout the maintenance branch e.g 1.8.x
  2. Add or Update any bundled modules you wish to include before creating the tag and then Commit the changes.
  3. Run mvn clean install, verify all tests are passed and no changes to be committed.
  4. Do some last minute rudimentary testing. See Testing Releases.
  5. There are two ways of tagging the release:
    1. Option 1: Automatic Maven way:
      1. Run mvn release:prepare -Dusername=<scm-username> -Dpassword=<scm-password>
        • The username/password can be omitted if the subversion credentials are cached.
      2. At the interactive prompts, enter the following:
        Release version: 1.8.0-RC
        Tag name: 1.8.0-RC
        Development version: 1.8.0-SNAPSHOT
        • To run in non-interactive mode, include the following with the release:prepare command:
          -B -DreleaseVersion=1.8.0-RC -Dtag=1.8.0-RC -DdevelopmentVersion=1.8.0-SNAPSHOT
      3. If a failure occurs, the release changes can be reverted by running mvn release:rollback, but committed tags will need be to removed manually.
        • If no changes have been committed to subversion, the release can also be cleaned up using mvn release:clean
    2. Option 2: Manually:
      1. Change the values of the version tags in the pom files to be '1.8.0-RC' the values of the scm URLs in the pom files to point to the new tag's location in the repository.
      2. Tag the branch with the name 1.8.0-RC. (Using the SVN Repository View in subclipse: right-click --> SVN Branch/tag). Remember to add any bundled modules you wish to include before creating the tag.
      3. In the 1.8.x branch, change the values of the version tags in the pom files back to "1", "8", "0", and modifier of "SNAPSHOT" e.g 1.8.0-SNAPSHOT, change the values of the scm URLs in the pom files to point to the 1.8.x branch's location in the repository. Commit the changes.
  6. Check out the '1.8.0-RC' tag and use it to build the archives with the maven 'package' goal and upload them to  OpenMRS Download Files
  7. Deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Create the Standalone. See the Standalone readme.txt file for how to build and package the standalone. Before you build the standalone please include the latest version of the CIEL dictionary by updating mvp-data.sql. After the standalone is packaged, add bundled modules to the war in openmrs-standalone/tomcat/webapps/openmrs-standalone.war/WEB-INF/bundledModules.
  9. Create the beta release notes page atRelease/Prelease Notes using all commits to trunk since the last release. e.g. Release Notes 1.8.0 RC
  10. Create the read me files, you can pick the ones from the prior releases at OpenMRS Download Files on sourceforge and edit it accordingly by updating the versions.
  11. Create a homepage news item by posting to blog.openmrs.org, you can use word press to create the blog.
  12. Send an announcement to the implementers and developers mailing lists.

Going from release candidate to full release requires that testing scripts 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 mailing list or dev call).

Major Release

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.

  1. Checkout the maintenance branch e.g 1.8.x
  2. Add or Update any bundled modules you wish to include before creating the tag and then Commit the changes.
    1. Check each module's page in the module repository to find the latest version.  You should use the latest version unless a module developer specifically requests that an earlier version be bundled.
  3. Run mvn clean install, verify all tests are passed and no changes to be committed
  4. Do some last minute rudimentary testing. See Testing Releases
  5. There are two ways of tagging the release:
    1. Option 1: Automatic Maven way:
      1. Run mvn release:prepare -Dusername=<scm-username> -Dpassword=<scm-password>
        • The username/password can be omitted if the subversion credentials are cached
      2. At the interactive prompts, enter the following:
        Release version: 1.8.0
        Tag name: 1.8.0
        Development version: 1.8.1-SNAPSHOT
        • To run in non-interactive mode, include the following with the release:prepare command:
          -B -DreleaseVersion=1.8.0 -Dtag=1.8.0 -DdevelopmentVersion=1.8.1-SNAPSHOT
      3. If a failure occurs, the release changes can be reverted by running mvn release:rollback, but committed tags will need be to removed manually
        • If no changes have been committed to subversion, the release can also be cleaned up using mvn release:clean
    2. Option 2: Manually:
      1. Change the values of the version tags in the pom files to be '1.8.0' the values of the scm URLs in the pom files to point to the new tag's location in the repository.
      2. Tag the branch with the name 1.8.0. (Using the SVN Repository View in subclipse: right-click --> SVN Branch/tag). Remember to add any bundled modules you wish to include before creating the tag.
      3. In the 1.8.x branch, change the values of the version tags in the pom files to "1", "8", "1", and modifier of "SNAPSHOT" e.g 1.8.1-SNAPSHOT, change the values of the scm URLs in the pom files to point to the 1.8.x branch's location in the repository. Commit the changes.
  6. Check out the '1.8.0' tag and use it to build the archives with the maven 'package' goal and upload them to  OpenMRS Download Files
  7. Deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Create the Standalone. See the Standalone readme.txt file for how to build and package the standalone. Before you build the standalone please include the latest version of the CIEL dictionary by updating mvp-data.sql. After the standalone is packaged, add bundled modules to the war in openmrs-standalone/tomcat/webapps/openmrs-standalone.war/WEB-INF/bundledModules.
  9. Create the beta release notes page at Release/Prelease Notes using all commits to trunk since the last release. e.g. Release Notes 1.8.0
  10. Create the read me files, you can pick the ones from the prior releases at OpenMRS Download Files on sourceforge and edit it accordingly by updating the versions.
  11. If you haven't already done so, open a support ticket to request an update to the OpenMRS.org home page and downloads page. It's better to request this in advance so it can go live at the same time of the release.
  12. Update the TRUNK project in JIRA with this maintenance release version number, if it's not already there. This can be done by the TRUNK project administrators/approvers and allows "Fix Version" and "Affects Version" to be specified for this release.
  13. Once you've confirmed the version is listed in JIRA, open a support ticket and request SCRAP be updated with this new version to allow automated error reports to be received for this version.
  14. Once you've confirmed the version is listed in JIRA, open a support ticket and request the OpenMRS.org http://openmrs.org/help/report-a-bug/ form be updated to allow bug reports to be received for this version.
  15. Delete the "latest" tag and then tag the tag you created above as latest (continuous integration and other automated processes use this "latest" tag for autobuilding the demo server).
  16. Send an announcement to the announce mailing list (sending mail to the announcement list is restricted; if you don't have access or don't know if you have access to the announce list, then ask support for help making an announcement to the community).
  17. Send an email about Unsupported Releases (EOL) for the version two back. (e.g. if releasing 1.8.0, then 1.5.x is now EOL).

Maintenance Release

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.

  1. Verify that there are no unreviewed open tickets against the version to be released.
    1. Review/close tickets are are in Post Commit Review.
    2. Look carefully at In Progress tickets to see if some of them have not been committed to a branch (back ported) already. You need to review/close such tickets as well.
    3. Move tickets to the next version that are In Progress or in Precommit Review stage (use Manage Versions admin page for bulk moving of tickets).
  2. Checkout the maintenance branch, e.g., 1.8.x
  3. Run:
  4. Verify all tests are passed and no changes to be committed.

  5. Run Liquibaserunner against the just built SNAPSHOT to make sure all liquibase tests pass.
  6. Do some last minute rudimentary testing as described in Testing Releases.
  7. There are two methods of tagging the release:
    1. Option 1: Automatic Maven method
      1. Make sure your IDE is not running before proceeding in the command line, because you may experience strange test failures. Run:

        The username/password can be omitted if the Subversion credentials are cached.

      2. At the interactive prompts, enter the following:
        Release version: 1.8.1
        Tag name: 1.8.1
        Development version: 1.8.2-SNAPSHOT
      3. To run in non-interactive mode, include the following options to the above command:

      4. If a failure occurs, the release changes can be reverted by running.

        Committed tags will need be to removed manually.

      5. To release run:

        This command will check out the 1.8.1 tag, build all artifacts and deploy them to the maven repository. Please make sure you have username and password configured for the openmrs-repo-releases maven repository in the .m2/settings.xml file.

    2. Option 2: Manual method
      1. Change the values of the version tags in the pom files to be 1.8.1 the values of the scm URLs in the pom files to point to the new tag's location in the repository.
      2. Tag the branch with the name, e.g., 1.8.1. Using the SVN Repository View in Subclipse, right-click and choose "SVN Branch/tag". Remember to add any bundled modules you wish to include before creating the tag.
      3. In the relevant release, e.g., 1.8.x, change the values of the version tags in the pom files to the value for the next release, e.g., "1", "8", "2", and modifier of "SNAPSHOT" e.g 1.8.2-SNAPSHOT, change the values of the scm URLs in the pom files to point to the 1.8.x branch's location in the repository. Commit the changes.
      4. Check out the 1.8.1tag and use it to build the archives with:

      5. Deploy the files to maven repository with the command mvn deploy --batch-mode. See Deploying Ant Releases Manually.
  8. Create the Standalone. See the Standalone readme.txt file for how to build and package the standalone. Before you build the standalone please include the latest version of the CIEL dictionary by updating mvp-data.sql. After the standalone is packaged, add bundled modules to the war in openmrs-standalone/tomcat/webapps/openmrs-standalone.war/WEB-INF/bundledModules.
  9. Upload the standalone and the war without bundled modules to the OpenMRS project on SourceForge. In the file listing page on Sourceforge, click the info "i" button to expand the details of the uploaded ZIP file. For "Download Button", type "Download OpenMRS 1.8.3 Standalone". Under "Default Download For:" check all the option boxes. Click "Save" to save the settings.
  10. Create the release notes wiki page and locate it under the Release Notes page. Use all commits to trunk since the last release. See, e.g., Release Notes 1.7.1. Update the include on the Release Notespage itself to point to the new page you just created.
  11. Create the README file. Use prior READMEs for guidance and upload the text file (no HTML) to the OpenMRS project on SourceForge.
  12. Create a blog post on OpenMRS.org using your WordPress account. If you need an account, open a ticket to request one
  13. Delete the "latest" tag in SVN and then tag the tag you created above as latest (continuous integration and other automated processes use this "latest" tag for autobuilding the demo server).
  14. If you haven't already done so, open a support ticket to request an update to the OpenMRS.org home page and downloads page. It's better to request this in advance so it can go live at the same time of the release.
  15. Update the TRUNK project in JIRA with this maintenance release version number, if it's not already there. This can be done by the TRUNK project administrators/approvers and allows "Fix Version" and "Affects Version" to be specified for this release.
  16. Once you've confirmed the version is listed in JIRA, open a support ticket and request SCRAP be updated with this new version to allow automated error reports to be received for this version.
  17. Once you've confirmed the version is listed in JIRA, open a support ticket and request the OpenMRS.org http://openmrs.org/help/report-a-bug/ form be updated to allow bug reports to be received for this version.
  18. Create a new version for the next maintenance release (if there will be one) Using the Manage Versions in https://tickets.openmrs.org/plugins/servlet/project-config/TRUNK.
  19. Close the current maintenance version using the above admin page.
    1. When you close a version it will allow you to move non-closed tickets to the next version.
  20. Send an announcement to the implementers and developers mailing lists.

About Release branches

A new release branch is created for each new major and minor release. (Reading Versioning would be helpful about now) So, for example, a new release branch is created when preparing to release version 2.0.0, or version 1.3.0. However, when preparing to release 1.3.1 (a maintenance-version increment), the release branch created at the time of 1.3.0 is used.

A new release branch needs to be created when the alpha is released. Generally, we have a soft schedule of releasing a new minor version every 2-3 months. So, approximately 2 months after the previous minor release is a good time to start proposing an alpha release and release branch creation. But remember that this is flexible, depending on what features are being developed.

Once a release branch has been created, no development ever takes place there. The only changes permitted are ones made to various bookkeeping files and changes merged in from trunk.

Troubleshooting

  • When releasing using the Automatic Maven method, you may some times get this error message: [ERROR] svn: MKACTIVITY of '/!svn/act/adeb5614-9496-4b46-b28e-eb5d1d6b3bc0': authorization failed: Could not authenticate to server: rejected Basic challenge (http://svn.openmrs.org). This is caused by an invalid svn user name or password. I also got the same error message when my user name and password were correct but the password had spaces in it. Resolving it required only changing my password to one which did not have spaces. But before you change your password, Ben suggests that you try enclosing it in double quotes and see if it works.
  • There are also times when you may get this error message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on project openmrs: Can't release project due to non released dependencies : This is caused by having SNAPSHOT dependencies (outside the current build) which should be released before you can release the project. Their released artifacts should be deployed to Nexus (through release process or manually if necessary). Then the pom.xml should be updated with the release versions and the trunk pom.xml should be bumped to their next SNAPSHOT versions, if development is continuing.
  • When running: mvn clean deploy --batch-mode  You 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.
  • When running: 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.
  • When running: 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 .

Tips

  • When doing release testing, creating standalone distributions can be a very quick and easy way.
  • No labels

7 Comments

  1. We should consider adding MD5 checksums to the download package that gets posted to the mirrors, given likelihood for poor connectivity in many places that download OpenMRS.

  2. I have tried to clean up part of this page and add in more accurate detail about publishing the releases. So far, I've only updated the "maintenance release" section. Other sections should be updated accordingly.

  3. If uploading to sourceforge, the syntax that worked for me is:

  4. Also see the Managing the Maven Repository wiki page for uploading artifacts to the maven repo

    1. Adding the -P switch helped with my poor connection, which keeps breaking, by resuming the upload from where it was before the connection interruption:

      rsync -P -e ssh openmrs-standalone-1.9.0-RC.zip dkayiwa@frs.sourceforge.net:/home/frs/project/o/op/openmrs/prereleases/OpenMRS_1.9.0_RC/

  5. I keep forgetting this. So am putting here as a comment for remembrance. This is how i usually delete the "latest" tag:

    git tag -d latest
    git push upstream :refs/tags/latest
  6. Then to tag "latest" as a particular commit hash (e.g 60bd9bce5888f64d78ea7db4a68b8bd932f36bb6), i use this:

    git tag -a latest 60bd9bce5888f64d78ea7db4a68b8bd932f36bb6 -m "Tagging OpenMRS 1.9.7 as latest"

    git push --tags upstream