Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Releases

1.

Code masters: The project operates with two code distribution masters, a development master used for active development, and a release master, established at the time of the last release.

2.

Patches: Check-in to the release master is permitted only to the designated release manager, and is confined to patches which meet the following criteria:

• Fix serious defects in capabilities included in the release.
• Are adequately isolated to allow patch generation.

Patches submitted by developers need to compile against the release master, as opposed to the development master. Each consortium site is expected accordingly to maintain a release build, or to use the project center release build to verify the correctness of any patch submitted. A mechanism is provided to end-users to update their binary releases with the accepted patches.

3.

OS support: The operating systems supported for each release are established by project management in consultation with the consortium. These are chosen on the basis of their prevalence, at a given revision level, within the user community targeted by AIPS++. The project may lag the highest revision levels available for a given operating system by this criterion. Binary releases are not necessarily prepared for all architectures used for development in the consortium. This depends on available resources.

4.

Developer support: Developer releases, which can be updated by the standard consortium code distribution system, will be made periodically, subject to available resources. The primary, but not sole, consumers of AIPS++, however, are the scientific end-users of the package.

5.

Stable releases: Stable releases are designated periodically during each development cycle. These are builds which meet acceptance standards, as certified by the Quality Assurance Group (QAG).