ARPS Code Update, Version Control and Release Policy
24 Sep 1998
DRAFT

1. Official releases shall consist of either

(a) a complete (3-digit, tertiary) version, or
(b) an update to a complete version, identified by a fourth digit.

2. Official releases shall never be modified. The date of the release shall be noted in the HISTORY file. Official releases shall be announced by email and by a web posting.

3. Officially releases shall be maintained in the following locations:

(a) the ftp server (tarred/gzipped; ftp.caps.ou.edu), and
(b) a disk accessible from both the Origin and the RS/6000 cluster (untarred; last 6 months only; origin:/official).

Between complete official releases of ARPS, official updates will be released as needed. They are intended primarily to address bug fixes or other simple changes. The updates will not necessarily be tested. They will contain all files modified since the previous complete official release, and only those files.

As an example, 4.9.1.update.2 will contain all files modified since 4.9.1 was released. (Thus there is no need to refer to 4.9.1.update.1.) A script will be provided to move the updated files to their proper location while preserving any existing files. The updated version may be referred to as 4.9.1.2.

4. A suite of basic tests will be performed before a complete version is released. These tests currently consist of several idealized tests (e.g., May 20, symmetry, density current, Beltrami flow) and a real data case [TBD]. Any variance in test results (due to changes in model algorithms, etc.) must be noted in the HISTORY file and be approved by the code's primary author.

It is the developer's responsibility, however, to perform tests that demonstrate that the effectiveness of the proposed changes. These tests should be run before the proposed changes are submitted. Once a "work" version is created, but before any official release, the maintainer may request that the developer re-run such tests.

Preliminary, untested ("beta") versions may sometimes be made available for testing by the Development Group. They shall be clearly identified as such (e.g., ".wrk"), and will be intended for testing only, not operational use. (Users are advised not to access files in the maintainer's work directory except by special arrangement.)

5. Developers shall request changes by sending email to the ARPS Development Group (arpsdev@listserv.ou.edu). (Mail sent to this address will automatically be sent to all members of the group and will be archived on a web page [TBD]. Thus, members may simply reply to the email without referring to the web page.) The developer shall describe

• the specific code change(s) that are to be made;
• tests that have been performed that demonstrate the accuracy of the proposed changes.
• whether the change should be made immediately as an update or whether it can wait till the next complete release;
• any other relevant information.

At the time the request is made, the maintainer will post an estimated time for making this change. He or she will also notify the group when the change is implemented in an officially released version. The purpose for this procedure is to avoid miscommunication and to involve more people in the development process.