Page Comparison

...

1. Select a tag name such as '3.0.0-beta' based on the OpenLMIS Releases guidelines in the wiki.
2. In each service, set the serviceVersion property in the gradle.properties file to the version you've chosen.  Tag this commit with that same version and push to GitHub.  Note that GitHub release tags should start with the letter "v", so '3.0.0-beta' would be tagged 'v3.0.0-beta'.  Also, when you create the version in GitHub check the "This is a pre-release" checkbox if indeed that is true.  Do this for each service/UI module in the project, including the API services and the AngularJS UI repo (note: in that repo, the file is called version.properties, not gradle.properties).  DON'T update the Reference Distribution yet.
   
   1. Do we need a release branch? For the 3.0 Beta release, we do not need a release branch, only a tag. If there are any later fixes we need to apply to the 3.0 Beta, we would issue a new beta release (eg, 3.0 Beta R1) to publish additional, specific fixes.
   2. Do we need a code freeze? We do not need a "code freeze" process. We will add the tag in Git, and everyone can keep committing further work on master as usual. Updates to master will be automatically built and deployed at the Test site (test.openlmis.org), but not the UAT site (uat.openlmis.org).
   3. Confirm that your release tags appear in GitHub and in Docker Hub.
      
      1. Look under the Releases tab of each repository, eg https://github.com/OpenLMIS/openlmis-requisition/releases.
      2. Look under Tags in each Docker Hub repository.  e.g. https://hub.docker.com/r/openlmis/requisition/tags/  .   You'll need to wait for the Jenkins jobs to complete and be succesfull so give this a few minutes.
         Note: After tagging each service, you may also want to change the serviceVersion again so that future commits are tagged on Docker Hub with a different tag. For example, after releasing '3.1.0' you may want to change the serviceVersion to '3.2.0-SNAPSHOT'.
3. In openlmis-config, tag the most recent commit with the tag version (including the 'v').
4. Update docker-compose.yml in openlmis-ref-distro with the release chosen
   1. For each of the services deployed as a the new version on DockerHub, update the version in the docker-compose.yml file to the version you're releasing. See the lines under "services:" → serviceName → "image: openlmis/requisition-refui:3.0.0-beta-SNAPSHOT" and change that last part to the new version tag for each service.
   2. Commit this change and tag the openlmis-ref-distro repo with the release being made.
5. Update docker-compose.yml in openlmis-deployment for the UAT deployment script with the release chosen which is at https://github.com/OpenLMIS/openlmis-deployment/blob/master/deployment/uat_env/docker-compose.yml
   
   1. For each of the services deployed as a the new version on DockerHub, update the version in the docker-compose.yml file to the version you're releasing.
   2. Commit this change. (You do not need to tag this repo because it is only used by Jenkins, not external users.)
6. Kick off each *-deploy-to-uat Jobs on Jenkins
   1. Wait about 1 minute between starting each job
   2. Confirm UAT has the deployed service.  e.g. for the auth service:  http://uat.openlmis.org/auth  check that the version is the one chosen.
7. Load demo data manually into UAT host's postgres container
8. Navigate to uat.openlmis.org and ensure it works
   
   

...