Difference between revisions of "How to Make a Release"

From OPeNDAP Documentation
m (Set Tasks for a Release)
m (Send out a notice.)
 
(87 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== 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.
To plan a sprint there are two basic sets of tasks: cleaning up the left over bugs that have accumulated during the past sprints and then working on a set of predictable tasks. This page lists those predictable tasks and some notes about the various releases. In the burndown chart built by Jira, there is a ''Time Spent'' column that tells how long each of the various tasks really took. While it's impossible to predict how long some of the stuff will take, previous performance is the best tool we've got, as they say...
 
  
== Set Tasks for a Release ==
+
# Look for any tickets that have been bound to the label 'fix release x.y.z' and make sure those are completed. Be sure to use both:
The tasks identified for Hyrax 1.12.2 and the time it took to complete them
+
#* The HyraxKB Kanban board in OPeNDAP's JIRA.
;Verify CI build and fix as needed: 6h
+
#* The Hyrax board in our NASA JIRA.
;Security Review libdap & bes: 6h
+
# When we are ready to release, follow the process outlined in the sections below.
;Security review OLFS: 1d
+
# Once done, close the board
;Source release libdap: 30m
 
;Source release BES: 3h 30m
 
;Build OLFS release bundles: 1h
 
;Build RPMs for release: 3h 30m
 
;Software packages on website: 30m
 
;Update Hyrax release pages on website: 2h
 
;Install new sever on test.opendap.org: 2h
 
  
;Total time used during Hyrax 1.12.2: 33h
+
== When we decide to release software ==
 +
Use the developers at opendap.org list to send out notices to all the developers about pending releases.
  
We did 9 other tasks too during the hyrax 1.12.2 release. The total time was planned as ''3w 1d 5h'' and turned out as ''1w 2d 2h 10m''.
+
=== 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!
 +
 
 +
=== 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.
 +
 
 +
== Release Prerequisites  ==
 +
Only start this process when hyrax-dependencies, libdap, bes and OLFS ''master'' branches all building and passing their tests.
 +
 
 +
== Steps For A Major Release (ex: 1.16.x -> 1.17.0) ==
 +
# <span style="text-decoration: line-through;">Security Review for libdap, BES and OLFS</span> Now Handled By TravisCI
 +
# Write a new X.Y web page. See the [https://docs.opendap.org/images/f/fe/Admin_instructions.pdf 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.
 +
# Follow the remaining steps for a ''minor'' release (below).
 +
 
 +
== Steps For A Minor Release (ex: 1.16.5 -> 1.16.6) ==
 +
; Notes
 +
* ''Committing and pushing the various changes made for the source releases will trigger a binary build and those binaries will have the version numbers made in the source distributions update.''
 +
 
 +
* ''Perform these steps in the order stated as downstream activities rely on items created in earlier steps, such as the creation of the DOIs for libdap and BES are required when updating the OLFS README.md, ''
 +
 
 +
=== Perform the [[Jira Release Process]] ===
 +
 
 +
 
 +
=== hyrax-dependencies: [[Source Release For hyrax-dependencies]] ===
 +
 
 +
=== libdap: [[Source Release for libdap]] ===
 +
 
 +
 
 +
=== BES: [[Source Release for BES]] ===
 +
 
 +
=== OLFS:  [[OLFSReleaseGuide | Source and Binary release for OLFS]] ===
 +
 
 +
=== [[Signing And Publishing C++ Binary Distributions]] ===
 +
: '''Note:''' ''This was already done for the java OLFS in the previous steps.''
 +
 
 +
=== [[HyraxDockerReleaseGuide | Build And Publish Docker Images For The Release]] ===
 +
 
 +
=== Install the new server on test.opendap.org ===
 +
 
 +
== [[Update The Hyrax Release Web Page]] ==
 +
== Send out a notice. ==
 +
Here's a sample email message. I sent this to: "OPeNDAP Inc." <opendap-tech@opendap.org>, opendap-announce@opendap.org, opendap@opendap.org
 +
 
 +
Subject: We are pleased to announce the release of Hyrax 1.16.8
 +
 
 +
<pre>
 +
Greetings!
 +
 
 +
OPeNDAP is pleased to announce the release of Hyrax 1.16.8. This version of the DAP2 and DAP4 data server is available as RedHat 8 and CentOS 7 RPM packages, Docker containers and source code via GitHub. See https://www.opendap.org/software/hyrax/1.16#SoftwareDownloads for the details.
 +
 
 +
Hyrax is Open Source.
 +
 
 +
Below are the changes/updates for this version of the server.
 +
 
 +
DMR++ Improvements - Direct subsetting access to data in S3
 +
 
 +
• Various improvements for supporting FillValue in dmr++ lifecycle.
 +
• Improved support for arrays of type String.
 +
• Fixed trusted url bug in DMZ parser.
 +
• Added support for "empty" valued scalars with associated _FillValue metadata.
 +
• get_dmrpp Improvements
 +
• Added support for S3 hosted granules to get_dmrpp
 +
bes
 +
 
 +
• Support for RHEL8
 +
• Improved the error messages returned to the client
 +
• Refactored get_dmrpp, application. Some test features are still broken but core functionality is working now.
 +
• Improved support for more GES DISC level 3 and level 4 products
 +
• Added coverage the support for the AIRS level 3 and GLDAS level products.
 +
• Patched bug in HDF5Array.cc introduced by the std::vector refactor
 +
• Added time.h header to ppt/SocketUtilities.cc
 +
• Modified fileout_netcdf handler to allow netcdf-3 responses to be up to 4GB in size.
 +
This behavior can be reverted by setting FONc.NC3ClassicFormat=true in the BES configuration
 +
(aka /etc/bes/site.conf file)
 +
olfs
 +
 
 +
• Improved the DAP4 Data Request Form (now the default form for the server)
 +
• Patched bug where unexpected Authentication headers would trigger a redirect loop.
 +
• Fixed the broken service that was failing to deliver flat (not-data) files to clients.
 +
• Made the "Get As NetCDF-3" an "Get As DAP2 Binary" buttons on the DAP4 Data Request Form context sensitive. If the dataset in question contains variables whose data types are found in DAP4 and not in DAP2/NetCDF-3 then the buttons are disabled. A more complete solution is envisioned where the projected variables are assessed and if only DAP2/NetCDF-3 types are selected then the buttons would would be enabled. This fix is only a step in that more dynamic direction.
 +
• Tested on Tomcat-9.0.x
 +
 
 +
Thank you for your continued support,
 +
 
 +
The Hyrax development team: Nathan Potter, Dan Holloway, Sam Lloyd, Kodi Neumiller, Kent Yang and James Gallagher
 +
 
 +
Acknowledgement: OPeNDAP thanks NASA and Raytheon for continued support of the Hyrax Data Server.
 +
 +
James Gallagher
 +
jgallagher@opendap.org
 +
</pre>
 +
 
 +
== Time to complete by release ==
 +
Update and of the release checklists and the 'Time to complete...' information below.
 +
 
 +
* 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
 +
* Hyrax 1.16.2: ''3d'' effort

Latest revision as of 17:08, 29 July 2022

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. Be sure to use both:
    • The HyraxKB Kanban board in OPeNDAP's JIRA.
    • The Hyrax board in our NASA JIRA.
  2. When we are ready to release, follow the process outlined in the sections below.
  3. Once done, close the board

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 Release Prerequisites

Only start this process when hyrax-dependencies, libdap, bes and OLFS master branches all building and passing their tests.

3 Steps For A Major Release (ex: 1.16.x -> 1.17.0)

  1. Security Review for libdap, BES and OLFS Now Handled By TravisCI
  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).

4 Steps For A Minor Release (ex: 1.16.5 -> 1.16.6)

Notes
  • Committing and pushing the various changes made for the source releases will trigger a binary build and those binaries will have the version numbers made in the source distributions update.
  • Perform these steps in the order stated as downstream activities rely on items created in earlier steps, such as the creation of the DOIs for libdap and BES are required when updating the OLFS README.md,

4.1 Perform the Jira Release Process

4.2 hyrax-dependencies: Source Release For hyrax-dependencies

4.3 libdap: Source Release for libdap

4.4 BES: Source Release for BES

4.5 OLFS: Source and Binary release for OLFS

4.6 Signing And Publishing C++ Binary Distributions

Note: This was already done for the java OLFS in the previous steps.

4.7 Build And Publish Docker Images For The Release

4.8 Install the new server on test.opendap.org

5 Update The Hyrax Release Web Page

6 Send out a notice.

Here's a sample email message. I sent this to: "OPeNDAP Inc." <opendap-tech@opendap.org>, opendap-announce@opendap.org, opendap@opendap.org

Subject: We are pleased to announce the release of Hyrax 1.16.8

Greetings!

OPeNDAP is pleased to announce the release of Hyrax 1.16.8. This version of the DAP2 and DAP4 data server is available as RedHat 8 and CentOS 7 RPM packages, Docker containers and source code via GitHub. See https://www.opendap.org/software/hyrax/1.16#SoftwareDownloads for the details.

Hyrax is Open Source.

Below are the changes/updates for this version of the server.

DMR++ Improvements - Direct subsetting access to data in S3

	• Various improvements for supporting FillValue in dmr++ lifecycle.
	• Improved support for arrays of type String.
	• Fixed trusted url bug in DMZ parser.
	• Added support for "empty" valued scalars with associated _FillValue metadata.
	• get_dmrpp Improvements
	• Added support for S3 hosted granules to get_dmrpp
bes

	• Support for RHEL8
	• Improved the error messages returned to the client
	• Refactored get_dmrpp, application. Some test features are still broken but core functionality is working now.
	• Improved support for more GES DISC level 3 and level 4 products
	• Added coverage the support for the AIRS level 3 and GLDAS level products.
	• Patched bug in HDF5Array.cc introduced by the std::vector refactor
	• Added time.h header to ppt/SocketUtilities.cc
	• Modified fileout_netcdf handler to allow netcdf-3 responses to be up to 4GB in size.
		This behavior can be reverted by setting FONc.NC3ClassicFormat=true in the BES configuration
		(aka /etc/bes/site.conf file)
olfs

	• Improved the DAP4 Data Request Form (now the default form for the server)
	• Patched bug where unexpected Authentication headers would trigger a redirect loop.
	• Fixed the broken service that was failing to deliver flat (not-data) files to clients.
	• Made the "Get As NetCDF-3" an "Get As DAP2 Binary" buttons on the DAP4 Data Request Form context sensitive. If the dataset in question contains variables whose data types are found in DAP4 and not in DAP2/NetCDF-3 then the buttons are disabled. A more complete solution is envisioned where the projected variables are assessed and if only DAP2/NetCDF-3 types are selected then the buttons would would be enabled. This fix is only a step in that more dynamic direction.
	• Tested on Tomcat-9.0.x

Thank you for your continued support,

The Hyrax development team: Nathan Potter, Dan Holloway, Sam Lloyd, Kodi Neumiller, Kent Yang and James Gallagher

Acknowledgement: OPeNDAP thanks NASA and Raytheon for continued support of the Hyrax Data Server.
—
James Gallagher
jgallagher@opendap.org

7 Time to complete by release

Update and of the release checklists and the 'Time to complete...' information below.

  • 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
  • Hyrax 1.16.2: 3d effort