Difference between revisions of "How to Make a Release"

From OPeNDAP Documentation
m (For a minor release)
m (For a minor release)
 
Line 44: Line 44:
 
#  
 
#  
 
# Update the links on the web page made/copies/edited above. Test each link - source and binary. Once all of those work...
 
# Update the links on the web page made/copies/edited above. Test each link - source and binary. Once all of those work...
# Sign the packages (source and binary). Do this by downloading the packages, signing and then uploading the ''.sig'' files - no need to upload the actual packages.
+
# Sign the packages (source and binary). Do this by downloading the packages, signing and then uploading the ''.sig'' files - no need to upload the actual packages. See [[SecureEmail | Secure Email]] for a hack to batch sign packages.
 
# Update the info for ''hyrax'' [[Docker container build]] in the Docker project on GitHub (See also [[HyraxDockerReleaseGuide | Hyrax Docker Release Guide]] which has some complimentary information).
 
# Update the info for ''hyrax'' [[Docker container build]] in the Docker project on GitHub (See also [[HyraxDockerReleaseGuide | Hyrax Docker Release Guide]] which has some complimentary information).
 
# Publish the release page. Check the links - there are links in two menus that have to be set manually.  
 
# Publish the release page. Check the links - there are links in two menus that have to be set manually.  

Latest revision as of 16:23, 10 July 2019

1 When we decide to release software

Use the developers at opendap.org list to send out notices to all the developers about pending releases.

1.1 Planned release

If this is a planned release, send out a notice at least two weeks in advance to anyone who likely has made changes to the software. More lead time is, of course, better. This will allow developers time to get their code and documentation changes into github and onto the master branch in time for the release.

Run Coverity!

1.2 Emergency releases

If this is an 'emergency' release, then send out a notice to developers as soon as the decision to release is made, since this will give a chance for other developers to lets us know if there are new changes in the master branch that are ready for release. if we don't get an email from those developers of a particular component, then we should assume that the code might not be 100% ready for release and we should use the version tagged with/for the last release if possible.

Maybe run Coverity - depends on the scope of the changes.

2 Overview

This is an updated set of notes regarding a software release. It is tailored to a release of Hyrax, but the same process can be used for any of our code.

  1. Look for any tickets that have been bound to the label 'fix release x.y.z' and make sure those are completed. Use the Kanban board.
  2. When we are ready to release, follow the process outlined in the section below.
  3. Once done, close the board

3 Set Tasks for a Release

Only start this process with libdap, bes and OLFS master branches all building and passing their tests.

3.1 For a major release

  1. Security Review for libdap, BES and OLFS
  2. Write a new X.Y web page. See the web site admin notes for info about this. It has important information about the menu links. Base this on the previous release page's structure/content.
  3. Follow the remaining steps for a minor release (below).

3.2 For a minor release

  1. Jira Release Process
  2. Update the release page on website, but don't publish it. For this, copy the X.Y page and make it X.Y.n. In the future, we might use only a single page for release X.Y and simply amend it with information for version .1, .2, and so on. Don't bother to edit the links, just get the text in place.
  3. Source release for hyrax-dependencies, libdap, BES and OLFS. Follow the itemized instructions for each. When you commit the various changes made for the source releases, that will trigger a binary build and those binaries will have the version numbers that making the source dists update.
    1. Make sure the hyrax-dependencies project is up to date and tar balls on www.o.o. If there have been changes/updates:
      1. Update version number for the hyrax-dependencies in the Makefile
      2. Save, commit, and push the changes to master branch.
      3. Once the hyrax-dependencies CI build is finished, trigger builds CI in both libdap4 and bes by pushing change(s) to the master branch of each.
      4. Tag, and push the tag. Make 'release' in github using the same basic process as for libdap and the bes
    2. Source Release for libdap In order to get the DOIs for libdap and BES into the OLFS README.md, you will need to make those before the OLFS source dist.
    3. Source Release for BES
    4. For the OLFS, Make the OLFS release Source and Binary release files. Follow these steps to create the three .jar files needed for the OLFS release.
  4. Install the new server on test.opendap.org
  5. Make and upload the source distributions for hyrax-dependencies, libdap, BES and, OLFS - delay signing until later.
  6. For the C++ software, Transfer the binary packages built using the CI/CD process. Log into the www.opendap.org web site host using ssh and the opendap account, and then use curl -O ... or wget --no-check-certificate ... to transfer the RPMs and Debian packages from our build.travis.opendap S3 bucket. The S3 bucket can be found at: https://s3.amazonaws.com/opendap.travis.build/index.html
  7. Update the links on the web page made/copies/edited above. Test each link - source and binary. Once all of those work...
  8. Sign the packages (source and binary). Do this by downloading the packages, signing and then uploading the .sig files - no need to upload the actual packages. See Secure Email for a hack to batch sign packages.
  9. Update the info for hyrax Docker container build in the Docker project on GitHub (See also Hyrax Docker Release Guide which has some complimentary information).
  10. Publish the release page. Check the links - there are links in two menus that have to be set manually.
  11. Send out a notice.
  12. Update and of the release checklists and the 'Time to complete...' information below.

3.3 Time to complete by release

  • Hyrax 1.12.2: The total time was planned as 3w 1d 5h and turned out as 1w 2d 2h 10m.
  • Hyrax 1.15.1: 3d calendar time