OLFSReleaseGuide: Difference between revisions

From OPeNDAP Documentation
Line 84: Line 84:
==== Tag the release ====
==== Tag the release ====
<font size="2"><source lang="bash">
<font size="2"><source lang="bash">
git tag -a version-<numbers> -m "Version <number>"
git tag -a version-<numbers> -m "OLFS <number>"
git push origin version-<numbers>
git push origin version-<numbers>

Revision as of 20:02, 2 November 2016

<< back to HowTo Guides


This document describes how to make releases of the OLFS.

For this document, $svn refers to the svn root, presumably "https://scm.opendap.org/svn".

About version numbers:

  • We use Hyrax <major>.<minor> version numbers for release branches.
  • We use <major>.<minor>.<revision> version numbers for the olfs code version.

New versions of a release (only the <revision> field in the version number is changed) should contain:

  • Bug fixes.
  • Updated tests.
  • Changes to production rules.

These changes should be made on the trunk and the merged to the release branch.

Since major development is only happening on development branches, very little on the trunk should change until a development branch is merged into the trunk. If new features are added or the code API changes there should be a new release made, which means make a new release branch.

This page is based on the branching and merging guidelines found here.

Make sure the code is ready to release

Make sure that all of the developers working on the code have checked in their working copies of the trunk, and that all development branches whose functionality/features/codeBase are to included in the release have been merged to the trunk and committed.

Check out the OLFS code from the subversion trunk

In a new directory get a fresh copy of the trunk:

git clone https://github.com/opendap/olfs

Build the OLFS

In the checked out OLFS directory run the command:

% ant server

Run the tests

Updated Jan 26th 2016

The OLFS utilizes an autotools/automake/autotest test system. In order to to run the tests you must build and install the BES first. Then build and install the OLFS into a Tomcat instance and start that instance.

NB - Do NOT specify version numbers at this stage as the test baselines are set up for the default version number of Not.A.Release. Building with a non-default version number will cause at least 12 tests to fail.

Once you have the OLFS built, installed, and running, return to the olfs top level directory and run:

make check

This will run the tests in a traditional autotest test harness.

Determine OLFS Version Number

  1. Look in the NEWS and README files to determine the previous version number.
  2. Determine new version number by looking at the changes to the code (start by reviewing the ChangeLog file)
    • Versioning rules: What the MAJOR.MINOR.REVISION string means:
      • No interfaces changed, only implementations (good): ==> Increment REVISION.
      • Interfaces added, none removed (good): ==> Increment MINOR, set REVISION to 0.
      • Interfaces removed or changed (BAD, breaks upward compatibility): ==> Increment MAJOR, set MINOR and REVISION to 0.
  3. Remember the new version number so that it can be used to:
    • Update the release related files
    • Build the versioned software distribution bundles.

Edit the release related files

Update the ChangeLog file using the script update_cl.sh which can be found in the svn-tools project. (e.g., ~/svn-tools/update_cl.sh ChangeLog). If you're making the first ChangeLog entries, then you'll need to create the ChangeLog file first. Then, to write the NEWS file, just read over the new ChangeLog entries and summarize.
Update version number.
Review content to make sure it's current.
Add new version number and,
Summarize the new additions to the change log. There may be many checkins associated with new feature development. You can summarize those as "Added 'X' feature."
Update version number.
Review content to make sure it's current.

Check in changes

In the local copy of the OLFS trunk in which you updated the ChangeLog and other files:

git commit -a -m "olfs: Updating olfs version and release files to version 1.2.3"

Once this is done, use github to tag the code you just committed both with its version and the version of hyrax to which it belongs:

Tag the release

git tag -a version-<numbers> -m "OLFS <number>"
git push origin version-<numbers>

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

git tag -a hyrax-<numbers> -m "Hyrax <number>"
git push origin hyrax-<numbers>
Instead of tagging all of the 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; recording the wrong version for one of the 17 or so modules. thus, there is no need to tag the code in the modules.

Build the versioned distribution bundles

In the local copy of the software:


This will create the three compressed tar files for the release in the $olfs/build/dist directory.

Contains the javadoc documentation for the release
Contains the source files for the release
Contains the instructions and .war file that will be used in the tomcat webapps directory.

Use GPG to detach sign each of these three files and you're ready to upload them to the website for distribution.

The OLFS has historically been published here: http://www.opendap.org/pub/olfs/