Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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.

...