The guide to making a release of the Hyrax Data Server
Hyrax is made of several software components. Some of these are OPeNDAP software others, like the hyrax-dependencies are code that Hyrax depends on that must be compiled by our process, and not brought in through a package manager. This is, in part, because some of our dependency libraries are customized for our work.
Our release products are:
- libdap As source and RPM binaries.
- hyrax The Hyrax data server bundled as a docker image.
- hyrax:ngap The Hyrax NGAP service bundled as docker image.
Hyrax is built from several component projects, each of which must be release in at least a most minimal way, for example just version numbers and git tags. Here are the Hyrax components, in the suggested order for the release process.
- hyrax-dependencies
- Internal Assets: Tarballs of the compiled dependency libraries for use in build the BES.
- Released assets: none.
- libdap4
- Released assets: Source code tarball & RPM files.
- bes
- Internal Assets: The
bes_coredocker image that will be used to make Hyrax docker containers. - Released assets: none.
- Internal Assets: The
- olfs
- Internal Assets: The various WAR files produced by the CICD build and used to assemble the Hyrax docker images.
- Released assets: none.
- hyrax_regression_tests
- Released assets: none.
- hyrax-docker
- Released assets: Hyrax docker images in DockerHub.
- Make a Hyrax release web page at www.opendap.org for this new release.
When making a release, for each of these components we need to:
- Update the component's base version number. (For example
1.18.7-->1.18.8or1.18.7-->1.19.0)- Update the component's Travis Build Offset and base version numbers.
- A GitHub release should be made for the component, and the associated DOI badges for each component collected from Zenodo for use in the release documentation.
James said, w.r.t. libdap:
I skimmed over this whole document in the repo and I think it's correct - it's hard to know without going through the process. But, there is one thing I'm sure of. There is (now) a better way to handle the DOI situation. Zenodo recognizes that software has versions and that embedding the DOI for a commit in a file that is part of that commit is a catch-22. So, they now have a DOI that doesn't change but always references the 'newest version.' It takes some hunting to find this, but once you do, this is set. You never need to update this in the README, etc.
I did this, so we can drop this step. See https://zenodo.org/records/14646648. There, on the right you will see:
Cite all versions? You can cite all versions by using the DOI 10.5281/zenodo.1013914. This DOI represents all versions, and will always resolve to the latest one. Read more.
The only thing that needs to be done WRT the DOI is to check that the tagging worked and that Zenodo really did archive a new release of the code.
Here's an evolving picture of the new release proces:
