Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

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. Update the branches section in the .travis.yml to match the branch name so that travis builds can be triggered for pull requests created against the branch.
  4. Add or Update any bundled modules you wish to include before creating the tag and then Commit the changes.
  5. Run mvn clean install, verify all tests are passed and no changes to be committed.
  6. Do some last minute rudimentary testing. See Testing Releases.
  7. Announce on the developer list that you are about to tag a release and make sure that everyone is prepared.
  8. There are three 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.
    3. Use the bamboo release button. This will also deploy files to the maven repository, hence making step 9 unnecessary. https://ci.openmrs.org
  9. Check out the '1.8.0-alpha' tag and use it to build the archives with the maven 'package' goal
  10. If you did not release from bamboo with option c in step 7 above, deploy the files to maven repository with the command mvn clean deploy --batch-mode
  11. Use the platform-distro project to generate the war file that contains the bundled modules, follow the instructions in the read me file and then upload war file to  OpenMRS Download Files
  12. Create the Standalone. See the Standalone readme.txt file Prepare to release a platform by setting versions of modules to be included in the platform at https://github.com/openmrs/openmrs-distro-platform/. Edit properties in the pom.xml file for the corresponding version branch 1.10.x, 1.11.x, etc. Use the latest released versions of modules.
  13. Release the platform using the bamboo release button of the corresponding platform version, see https://ci.openmrs.org/browse/OP
  14. Create a war file by building the openmrs-distro-platform and upload the war file to  OpenMRS Download Files
  15. 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.
  16. 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
  17. 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.
  18. Send an announcement to the implementers and developers mailing lists.
  19. Create a release blog post on OpenMRS.org using your WordPress account. If you need an account, create a help desk case at https://help.openmrs.org/customer/portal/emails/new
  20. 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.
  21. In the master branch, create a new liquibase update file for the next major version, and include it in the liquibase-update-to-latest.xml file. For instance, if the next major version is 2.2, create a file named liquibase-update-to-2.2.xml and include it in this file.

...

  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 three 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.
    3. Use the bamboo release button. This will also deploy files to the maven repository, hence making step 7 unnecessary. https://ci.openmrs.org
  6. Check out the '1.8.0-beta' tag and use it to build the archives with the maven 'package' goal
  7. If you did not release from bamboo with option c in step 5 above, deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Use the platform-distro project to generate the war file that contains the bundled modules, follow the instructions in the read me file and then upload Prepare to release a platform by setting versions of modules to be included in the platform at https://github.com/openmrs/openmrs-distro-platform/. Edit properties in the pom.xml file for the corresponding version branch 1.10.x, 1.11.x, etc. Use the latest released versions of modules.
  9. Release the platform using the bamboo release button of the corresponding platform version, see https://ci.openmrs.org/browse/OP
  10. Create a war file by building the openmrs-distro-platform and upload the war file to  OpenMRS Download Files
  11. 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.
  12. Create the beta release notes page under Prereleases using all commits to trunk since the last release. e.g. Release Notes 1.8.0
  13. 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.
  14. Send an announcement to the implementers and developers mailing lists.

...

  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 three 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.
    3. Use the bamboo release button. This will also deploy files to the maven repository, hence making step 7 unnecessary. https://ci.openmrs.org
  6. Check out the '1.8.0-RC' tag and use it to build the archives with the maven 'package' goal
  7. If you did not release from bamboo with option c in step 5 above, deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Use the platform-distro project to generate the war file that contains the bundled modules, follow the instructions in the read me file and then upload war file to  OpenMRS Download Files
  9. 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.
  10. Create the beta release notes page atRelease/Prepare to release a platform by setting versions of modules to be included in the platform at https://github.com/openmrs/openmrs-distro-platform/. Edit properties in the pom.xml file for the corresponding version branch 1.10.x, 1.11.x, etc. Use the latest released versions of modules.
  11. Release the platform using the bamboo release button of the corresponding platform version, see https://ci.openmrs.org/browse/OP
  12. Create a war file by building the openmrs-distro-platform and upload the war file to  OpenMRS Download Files
  13. 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.
  14. 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
  15. 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.
  16. Send an announcement to the implementers and developers mailing lists.

...

  1. Checkout the maintenance branch e.g 1.8.x
  2. You may have to prepare any pointed out module(s) to be bundled with openmrs, we are currently including only the rest webservices module, the bundled module will be added to the war file immediately after you have built one after tagging by creating a folder called bundledModules and adding the module inside it then open the war file with any archive manager software of your preference and then drug and drop the bundledModules folder containing the module(s) into /WEB-INF/ of the war file. Otherwise use https://github.com/openmrs/openmrs-distro-platform to release the OpenMRS Platform
    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 three 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
      4. Deploy the artifacts to the maven repo, make sure you have username and password configured for the openmrs-repo-releases maven repository in the .m2/settings.xml file.
        • Run mvn release:perform
    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.
    3. Use the bamboo release button. This will also deploy files to the maven repository, hence making step 7 unnecessary. https://ci.openmrs.org
  6. Check out the '1.8.0' tag and use it to build the archives with the maven 'package' goal
  7. If you did not release from bamboo with option c in step 5 above, deploy the files to maven repository with the command mvn clean deploy --batch-mode
  8. Use the platform-distro project to generate the war file that contains the bundled modules, follow the instructions in the read me file and then upload war file to  OpenMRS Download Files
  9. 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.
  10. Create the release notes page as a child of Platform Release Notesand include JIRA filters showing all closed tickets (e.g.Platform Release Notes 1.11.0)
  11. 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.
  12. 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 and DO NOT mark  Impact as anything other than "Routine."
    1. Asking to update the OpenMRS.org home page and downloads page. 
    2. Requesting SCRAP to be updated with this new version to allow automated error reports to be received for this version.
    3. Requesting the http://openmrs.org/help/report-a-bug/ form be updated to allow bug reports to be received for this version.
    4. Tell them about the time & date that the release will be ready, so that they know when to update the relevant public pages.
    5. It is helpful to provide them with the internal JIRA version number found in the URL for that version. Example, for “Platform 1.11.4” the JIRA version number is “17601” as seen in the URL for that version: https://issues.openmrs.org/browse/TRUNK/fixforversion/17601/
    6. To prevent confusion, it is also helpful to give them the URL to the release notes page and released files on Sourceforge, e.g., http://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_1.11.4/openmrs-standalone-1.11.4.zip/download
  13. If the current Reference Application is based on a SNAPSHOT of the version you just released, then update the reference application to build with your just-released version. (You can check and fix the openMRSVersion property in https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/pom.xml. For example if the property was set to 1.11.0-SNAPSHOT and you just released 1.11.0, change the property to 1.11.0.)
  14. 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.

  15. Once helpdesk confirms all is set for the release, make an announcement at https://talk.openmrs.org/c/software/openmrs-platform and/or https://talk.openmrs.org/c/software/openmrs-2-x . Include information about Unsupported Releases (EOL) for the version two back. (e.g. if releasing 1.8.0, then 1.5.x is now EOL).
  16. Edit the wiki page Platform Release Notes so that it includes as content the release notes.

Maintenance Release

...

  1. Prepare to release a platform by setting versions of modules to be included in the platform at https://github.com/openmrs/openmrs-distro-platform/. Edit properties in the pom.xml file for the corresponding version branch 1.10.x, 1.11.x, etc. Use the latest released versions of modules.
  2. Release the platform using the bamboo release button of the corresponding platform version, see https://ci.openmrs.org/browse/OP
  3. Create a war file by building the openmrs-distro-platform and upload the war file to  OpenMRS Download Files
  4. 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.
  5. Create the release notes page as a child of Platform Release Notesand include JIRA filters showing all closed tickets (e.g.Platform Release Notes 1.11.0)
  6. 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.
  7. 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 and DO NOT mark  Impact as anything other than "Routine."
    1. Asking to update the OpenMRS.org home page and downloads page. 
    2. Requesting SCRAP to be updated with this new version to allow automated error reports to be received for this version.
    3. Requesting the http://openmrs.org/help/report-a-bug/ form be updated to allow bug reports to be received for this version.
    4. Tell them about the time & date that the release will be ready, so that they know when to update the relevant public pages.
    5. It is helpful to provide them with the internal JIRA version number found in the URL for that version. Example, for “Platform 1.11.4” the JIRA version number is “17601” as seen in the URL for that version: https://issues.openmrs.org/browse/TRUNK/fixforversion/17601/
    6. To prevent confusion, it is also helpful to give them the URL to the release notes page and released files on Sourceforge, e.g., http://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_1.11.4/openmrs-standalone-1.11.4.zip/download
  8. If the current Reference Application is based on a SNAPSHOT of the version you just released, then update the reference application to build with your just-released version. (You can check and fix the openMRSVersion property in https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/pom.xml. For example if the property was set to 1.11.0-SNAPSHOT and you just released 1.11.0, change the property to 1.11.0.)
  9. 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.

  10. Once helpdesk confirms all is set for the release, make an announcement at https://talk.openmrs.org/c/software/openmrs-platform and/or https://talk.openmrs.org/c/software/openmrs-2-x . Include information about Unsupported Releases (EOL) for the version two back. (e.g. if releasing 1.8.0, then 1.5.x is now EOL).
  11. Edit the wiki page Platform Release Notes so that it includes as content the release notes.

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. Code Block
    mvn clean install

    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 three 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:

        Code Block
        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.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:

        Code Block
        -B -DreleaseVersion=1.8.1 -Dtag=1.8.1 -DdevelopmentVersion=1.8.2-SNAPSHOT
      4. If a failure occurs, the release changes can be reverted by running.

        Code Block
        mvn release:rollback

        Committed tags will need be to removed manually.

      5. To release run:

        Code Block
        mvn release:perform

        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. Use mvn clean deploy --batch-mode in-cases when experiencing any issues while uploading the artifacts.

      Option 2: Manual method
      1. Change  1.8.2-SNAPSHOT
      2. To run in non-interactive mode, include the following options to the above command:

        Code Block
        -B -DreleaseVersion=1.8.1 -Dtag=1.8.1 -DdevelopmentVersion=1.8.2-SNAPSHOT
      3. If a failure occurs, the release changes can be reverted by running.

        Code Block
        mvn release:rollback

        Committed tags will need be to removed manually.

      4. To release run:

        Code Block
        mvn release:perform

        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. Use mvn clean deploy --batch-mode in-cases when experiencing any issues while uploading the artifacts.

    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 be the value for the next release, e.g., "1", "8", "2", and modifier of "SNAPSHOT" e.g 1.8.1 the 2-SNAPSHOT, change the values of the scm URLs in the pom files to point to the new tag1.8.x branch's location in the repository.Tag the branch with the name, e.g., the repository. Commit the changes.
      4. Check out the 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.
      5. 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.
      6. Check out the 1.8.1tag and use it to build the archives with:

        Code Block
        mvn clean install
        mvn javadoc:jar
        mvn source:jar 
      7. Deploy the files to maven repository with the command mvn deploy --batch-mode. See Deploying Ant Releases Manually.
      Use the bamboo release button. This will also deploy files to the maven repository. 
      1. tag and use it to build the archives with:

        Code Block
        mvn clean install
        mvn javadoc:jar
        mvn source:jar 
      2. Deploy the files to maven repository with the command mvn deploy --batch-mode. See Deploying Ant Releases Manually.
    3. Use the bamboo release button. This will also deploy files to the maven repository. https://ci.openmrs.org
  8. Prepare to release a platform by setting versions of modules to be included in the platform at https://github.com/openmrs/openmrs-distro-platform/. Edit properties in the pom.xml file for the corresponding version branch 1.10.x, 1.11.x, etc. Use the latest released versions of modules.
  9. Release the platform using the bamboo release button of the corresponding platform version, see https://ci.openmrs.orgUse the platform-distro project to generate the war file that contains the bundled modules, follow the instructions in the read me file and then upload /browse/OP
  10. Create a war file by building the openmrs-distro-platform and upload the war file to  OpenMRS Download Files
  11. 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.
  12. 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.
  13. Create the release notes page as a child of Platform Release Notes and include JIRA filters showing all closed tickets (e.g. Platform Release Notes 1.11.1)
    • Use Finding Database Changes Between Releases to put the db changes into the release notes page.
    • Edit the Platform Release Notes page to include as content the new release notes page you just created, and updated it to give the new version number.
    • Update the Releases page to include the new platform release, (replacing the prior version in the release line this is a maintenance release in)
    • Update and modify the Downloads wiki page with the latest release notes page.
  14. Create the README file. Use prior READMEs for guidance and upload the text file (no HTML) to the OpenMRS project on SourceForge.
  15. If the current Reference Application is based on a SNAPSHOT of the version you just released, then update the reference application to build with your just-released version. (You can check and fix the openMRSVersion property in https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/pom.xml. For example if the property was set to 1.11.1-SNAPSHOT and you just released 1.11.1, change the property to 1.11.1.)
  16. 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.
  17. 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.
    1. Asking to update the OpenMRS.org home page and downloads page. 
    2. Requesting SCRAP to be updated with this new version to allow automated error reports to be received for this version.
    3. Requesting the http://openmrs.org/help/report-a-bug/ form to be updated to allow bug reports to be received for this version.
    4. Tell them about the time & date that the release will be ready, so that they know when to update the relevant public pages.
    5. It is helpful to provide them with the internal JIRA version number found in the URL for that version. Example, for “Platform 1.11.4” the JIRA version number is “17601” as seen in the URL for that version: https://issues.openmrs.org/browse/TRUNK/fixforversion/17601/
    6. To prevent confusion, it is also helpful to give them the URL to correct released files on Sourceforge, e.g., http://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_1.11.4/openmrs-standalone-1.11.4.zip/download
  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. Once helpdesk confirms all is set for the release, create a blog post on OpenMRS.org using your WordPress account. If you need an account, create a help desk case at https://help.openmrs.org/customer/portal/emails/new
  21. Send an announcement to the implementers and developers mailing lists/Instead just write a post that announces the released on talk under Software category.

...