OLFSReleaseGuide: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
Line 130: Line 130:
First get a copy of the new tagged version from svn:
First get a copy of the new tagged version from svn:


<font size="2"><source lang="sh">svn co $svn/tags/olfs/hyrax-4.5.0</source></font>


In your local copy of the release branch:
In the local copy of the tag build the software:


<font size="2"><source lang="sh">% ant -DOLFS_VERSION=1.2.3  -DHYRAX_VERSION=4.5.0 DISTRO</source></font>
<font size="2"><source lang="sh">% ant -DOLFS_VERSION=1.2.3  -DHYRAX_VERSION=4.5.0 DISTRO</source></font>

Revision as of 19:52, 13 September 2013

<< back to HowTo Guides

Overview

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:

svn co https://scm.opendap.org/svn/trunk/olfs

Build the OLFS

In the checked out OLFS directory run the command:

% ant server

Run the make-check script located in the olfs directory

This script will run a series of tests between the OLFS and an already installed BES. The BES should be configured with the netcdf_handler, freeform_handler, and hdf4_handler modules. If it's not already running the make-check script will start it. Or you can start the BES yourself. This requires that hyrax is running on localhost:8080.

% make-check

Note: You can use the script mkTestPatch to see the diffs of any broken tests.

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

ChangeLog
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. Here's a key tip: When you're making the commit log entries, always include the file name(s) of the affected files in your entry. Then to write the NEWS file, just read over the new ChangeLog entries and summarize. In the old days of CVS, the logs automatically included the names of the changed files, but subversion doesn't do that. A little discipline with those log entries will go a long way toward streamlining the release process!
README
Update version number.
Review content to make sure it's current.
NEWS
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."
install.html
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:

svn ci -m "olfs: Updating olfs version and release files to version 1.2.3"

The release branch

Question for James
So what happens if the OLFS changes a lot on the trunk and the C++ code does not. Since release branch name is tied to a Hyrax version (ex: branch/olfs/release/hyrax-1.9) and the rule is to make a new release branch, what do? Do we abandon the hyrax release branch and make one named something like branch/olfs/release/olfs-1.10.2 ?? But then what if I also make changes to the OLFS to fix a bug for the hyrax-1.9 release and those are on the trunk too.
It's kind of like the two bodies of code don't progress in lock step.
Maybe the answer is that we don't merge development branches to the trunk until we are getting ready for a new release?
ndp 19:43, 12 September 2013 (PDT)

If the release branch does not exist then create it

Naming the release branch
Since every release of the OLFS is tied to a release of the Hyrax server we create OLFS release branches based the name of the Hyrax release with which they are associated.
svn cp -m "olfs: Creating OLFS release branch for hyrax-4.5" $svn/trunk/olfs $svn/branch/olfs/release/hyrax-4.5

Otherwise (the release branch exists) so merge the trunk to the branch

Checkout a copy of the release branch:

svn co https://scm.opendap.org/svn/branch/olfs/release/hyrax-4.5

In this new local copy of the release branch merge from the trunk like this:

svn merge $svn/trunk/package

You need to run this command from within a working copy and the changes are made to the working copy. You need to commit them to add them to the repository.

svn ci -m "olfs: Merged trunk to hyrax-4.5 release branch."

Tag the release

Determining the tag name
The tag should be named with the name and full version number of the Hyrax release.
  • If you created a new release branch (which is always named with the major.minor version) called hyrax-4.5 then the tag name will be hyrax-4.5.0
  • If you are releasing a new version of an existing release then the version field should be incremented by one from the previous version. So if the most recent tag was hyrax-4.5.6 then the new tag should be hyrax-4.5.7


Example: A new release branch was just created

And the new release branch is named hyrax-4.5 then add a 0 as the revision number for a tag name of hyrax-4.5.0

svn cp -m "olfs: Tagging OLFS release for hyrax-4.5.0" $svn/branch/olfs/release/hyrax-4.5 $svn/tags/olfs/hyrax-4.5.0

Example: Releasing a new revision an existing release

And the most recent release tag was hyrax-4.5.6 then add a increment the revision field for a tag name of hyrax-4.5.7

svn cp -m "olfs: Tagging OLFS release for hyrax-4.5.7" $svn/branch/olfs/release/hyrax-4.5 $svn/tags/olfs/hyrax-4.5.7

Build the versioned distribution bundles

Build the OLFS distribution files by running ant and providing both the Hyrax version and OLFS version.

First get a copy of the new tagged version from svn:

svn co $svn/tags/olfs/hyrax-4.5.0

In the local copy of the tag build the software:

% ant -DOLFS_VERSION=1.2.3  -DHYRAX_VERSION=4.5.0 DISTRO

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

olfs-1.2.3-doc.tgz
Contains the javadoc documentation for the release
olfs-1.2.3-src.tgz
Contains the source files for the release
olfs-1.2.3-webapp.tgz
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/