Uniaud Release Procedures
These procedures have developed through discussions and experience for ensuring supportability of the packages and the constructiveness for development of feedback on official releases. They will surely need to be revised after the release of 1.1.4GA.
The Designated Release Builder
The Uniaud project has a single designated builder for the complete public release packages. This was decided specifically to control any possible variation between build tools and methods while the 1.1.4 code is being stabilized. Currently, this is Brendan.
If a new release package is desired, the designated builder should be approached. The designated builder is not, by that designation, the arbiter of whether or when releases are made, so he should comply with any reasonable request for a release.
Following are the steps the designated builder should follow.
Notify the uniaud-dev list
The designated builder announces the intent to release, letting the requester remain secret if desired. 24 hours are allowed for responses. Devs with work in progress then have the opportunity to ask for enough time to include their work, or else to hold off committing (freeze) until after the release. Frequently this results in small last-minute improvements to the package contents or documentation.
Update the Changelog and version numbers
The designated builder reviews the svn log of commits since the last release package and describes the changes in a manner relevant to users and useful for historical review, giving credit where due, and adds this to the Changelog in the svn repo. When this is committed, the "RC" number in the fixpack level is incremented in Uniaud.inc for both Uniaud32 and Uniaud16.
Build and privately distribute the Release Package
The designated builder checks that his source tree is up to date and clean, then builds Uniaud32.sys from trunk, Uniaud16.sys, and the installer files. He assembles the zip file based on the file list from the last release, and any changes that were decided. Then sends this in an email to the list of core contributors for review. The designated builder specifies in the message how it was built, and the versions of the tools used, highlighting anything different from previous releases. 24 hours are allowed for responses.
This review is important for checking for any mistakes or omissions in the package, last-minute driver tests, and dry-runs of the installer (whose snags frequently are caught at this point).
If anything is corrected, the designated builder re-sends the updated package to all, and the 24-hour clock for review is restarted.
Tag and Upload to Netlabs
Once the review has passed, the package is uploaded to Netlabs ftp, and Adrian is asked to move it to /pub/uniaud. At the same time, tags are created in Subversion for Uniaud32 and Uniaud16 so the code for the release is explicitly available.
svn copy -m "Tag of Uniaud32 1.1.4RCx" http://svn.netlabs.org/repos/uniaud/GPL/trunk
http://svn.netlabs.org/repos/uniaud/GPL/tags/1.1.4RCx
svn copy -m "Tag of Uniaud16 1.1.4RCx" http://svn.netlabs.org/repos/uniaud/OCO/trunk
http://svn.netlabs.org/repos/uniaud/OCO/tags/1.1.4RCx
Create Version in Trac
The release version, with its release date, is immediately added to Trac in the Admin section, and made the default, so new tickets refer to it.
Send Announcements
After Adrian has moved the package, the release is announced on uniaud-user and os2voice.org.
Debug Build Packages
As soon as practical (ideally at the same time as the release upload, but usually a bit later) the designated builder builds and uploads the debug package to Netlabs. This is Uniaud32 and Uniaud16, built from the same code as the release, but with DEBUG enabled. Like the release, the package contents are based on the previous one, and the Readme.debug is updated as needed. The drivers should be tested by at least one dev first, two if practical.
