Source Release for BES

From OPeNDAP Documentation
Revision as of 22:35, 26 November 2018 by Jimg (talk | contribs) (==)

Note that the old pages with the tables of version numbers are gone. Use the web pages themselves as documentation of what has or has not been built. For the current release, include grayed-out links to binaries we do plan to make but keep the grayed-out links in place for the current version only!

1 When we decide to release software

Use the developers at 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 The Release Process

Tip: If, while working on the release, you find you need to make changes to the code and you know the CI build will fail, do so on a release branch that you can merge and discard later. If you don't need to do this, do not make a release branch since it complicates making tags.

2.1 Verify the code base

  1. We release using the master branch. The code on master must pass the CI build.
  2. Make sure that the source code you're using for the following steps is up-to-date. (git pull)

2.2 Update Release Related Files

Update the text documentation files and version numbers in the configuration files:

2.2.1 Update the ChangeLog file.

Use the script gitlog-to-changelog (which can be found with Google) to update the ChangeLog file by running it using the --since="<date>" option with a date one day later in time than the newest entry in the current ChangeLog.

gitlog-to-changelog --since="1970-01-01" (Specify a date one day later than the one at the top of ChangeLog)

Save the result to a temp file and combine the two files:

cat tmp ChangeLog > ChangeLog.tmp; mv ChangeLog.tmp ChangeLog

If you're making the first ChangeLog entries, then you'll need to create the ChangeLog file first.
Tip: When you're making the commit log entries, use line breaks so ChangeLog will be readable. That is, use lines < 80 characters long.

Affected Files

2.2.2 Update the NEWS file

To update the NEWS file, just read over the new ChangeLog entries and summarize.

Affected Files

2.2.3 Updating the Human Version Number

  1. Determine the human version number. This appears to be a somewhat subjective process.
  2. Edit each of the Affected Files and update the human version number.
Affected Files
debian/changelog (see

It's helpful to have, in the NEWS file and the Web site and the release notes, a list of the Jira tickets that have been closed since the last release. The best way to do this is to goto Jira's Issues page and look at the Tickets closed recently item. From there, click on Advanced and edit the time range so it matches the time range since the past release to now, then Export that info as an excel spreadsheet (the icon with a hat and a down arrow). YMMV regarding how easy this is and Jira's UI changes often.

2.2.4 Update the RPM dependencies

In the RPM .spec file, update the dependencies as needed.

Affected Files

2.2.5 Update the internal library version numbers

There are really 2 version numbers for each of these project items. The human version (like bes-3.17.5) and the library API/ABI version which is represented as CURRENT:REVISION:AGE. There are special rules for when each of the numbers in the library API/ABI version get incremented that are triggered by the kinds of changes that where made to the code base. The human version number is more arbitrary. So for example, we might make a major API/ABI change and have to change to a new Libtool version like 25:0:0 but the human version might only change from bes-3.17.3 to bes-3.18.0

The rules for shared image version numbers:

  1. No interfaces changed, only implementations (good): Increment REVISION.
  2. Interfaces added, none removed (good): Increment CURRENT, increment AGE, set REVISION to 0.
  3. Interfaces removed or changed (BAD, breaks upward compatibility): Increment CURRENT, set AGE and REVISION to 0.

See How to see the scope of API/ABI changes in C++ sources below for gruesome details. Often basic knowledge of the edits is good enough.

Affected Files

2.2.6 For the BES HDF4/5 modules

  1. Goto those directories and update the ChangeLog, NEWS, README, and INSTALL files (even though INSTALL is not used by many).
  2. Update the module version numbers in their respective files.
  3. Commit and Push these changes.

2.3 Commit and Tag

  1. Commit and push the libdap, BES and OLFS ocde. With each operation, wait for the CI/CD builds to complete. You must be working on the master branch to get the CD package builds to work.

2.3.1 Tag The Release

  1. git tag -a version-<numbers> -m "Version <number>"
  2. git push origin version-<numbers>

If this is part of Hyrax, also tag this point in the master branch with the Hyrax release number:

  1. git tag -a hyrax-<numbers> -m "Hyrax <number>"
  2. git push origin hyrax-<numbers>
    NB: Instead of tagging the HDF4/5 modules, use the saved commit hashes that git tracks for submodules. This cuts down on the bookkeeping for releases and removes one source of error.
  3. Mark the release on Github:
    • Goto the 'releases' page and click the 'Tags' tab. There, click the ellipses (...) on the right of the 'version-*' tag and:
      • Enter a title for the release
      • Copy the most recent text from the NEWS file into the describe field
      • Click Update this release or Save draft

2.4 How to see the scope of API/ABI changes in C++ sources

Determine the new software version (assuming you don't already know the extent of the changes that have been made)

For C++, build a file of the methods and their arguments using:
nm .libs/libdap.a | c++filt | grep ' T .*::' | sed 's@.* T \(.*\)@\1@' > libdap_funcs
and compare that using diff on the previous release's library.

Assess the changes you find based on the following rules for the values of CURRENT,REVISION, and AGE

  • No interfaces changed, only implementations (good): ==> Increment REVISION.
  • Interfaces added, none removed (good): ==> Increment CURRENT, increment AGE, set REVISION to 0.
  • Interfaces removed or changed (BAD, breaks upward compatibility): ==> Increment CURRENT, set AGE and REVISION to 0.

The current value of CURRENT,REVISION, and AGE can be found in


Once you have determined the new values of the CURRENT:REVISION:AGE strings then:

Edit the and update the version values to the new ones.

3 Build The Release RPM and Source Distributions