<title>ACE+TAO Development and Release Process</title>
<link rev=made href="mailto:firstname.lastname@example.org">
<body text = "#000000"
<h3>The ACE+TAO+CIAO+DAnCE Development and Release Process</h3>
To improve the quality of our software and minimize development
effort, we try to follow the structured development and release
process described below.<p>
An important concept to keep in mind is <em>risk</em>. Before you
commit <em>any</em> change to ACE+TAO+CIAO+DAnCE, please consider the effects
that it will have. Could it possibly cause a build failure, on any
platform? Could it possibly cause different run-time behavior? And
so on. If so, it is your responsibility to adequately build and test
with the change, in order to verify that it has no unintended
Please keep in mind the cost of committing a mistake. It may take you
only a few seconds to fix, but its cost to the group may be much
larger. With our large group, workspace updates and builds are likely
to happen at any time. If one break, it can take hours to rebuild it.
And each developer that was waiting for a successful build would be
blocked for the duration of the broken build, the fix, and the
<h3>The ACE+TAO+CIAO+DAnCE Development Process</h3>
The ACE+TAO+CIAO+DAnCE development process looks like:<p>
<li>Every change to ACE+TAO+CIAO+DAnCE must have a bug report. <em>Change</em>
includes fixes, enhancements, updates, and so on.
<li><a href="http://bugzilla.dre.vanderbilt.edu/">Create a
<li>Accept the bug report if you are going to implement the change.
<li>Implement the change in your workspace(s) using a branch. Clearly
document each commit because that information is gathered into our
<li>Test the change sufficiently to demonstrate that it both does
what is intended, and doesn't break anything. The test may be
as simple as building and running the ACE+TAO+CIAO+DAnCE tests on at least two
Or as complicated as rebuilding and test all of ACE+TAO+CIAO+DAnCE on
all platforms that we have.
<li>Merge the changes only to master when
you are available the next 3 days to resolve any issues.
If you aren't available, hold your merge until you are available
<li>Respond to the requester of the change, if any. Please do this
<em>after</em> merging your change.
<li>Make sure that the requester is listed in the THANKS file.
<li>Update the bug report to indicate resolution.
<li>Monitor the next round of build/tests for problems with your change.
Because there are slow systems it can take up to 4 days to get all builds done.
<li>Respond immediately to reports of problems with your changes.
A bug should typically follow this life cycle:<p>
<center><table cellpadding=5 border=0>
<td>Reproduces problem - if it needs a new test, write it and
put it in the regression tests.
If it can't be reproduced, set to Resolved/CANT_FIND.<br>
If it's a duplicate, set it to Resolved/DUPLICATE.
Fix code, commit changes, set to Resolved.</td>
<td>Tests it again; set to Verified (pass) or Reopened (fail)</td>
<td>After next release is done, re-test; sets to Closed or Reopened.</td>
<H3>The Role of the Build Czar</H3>
At all times, we'll have a build czar. The role may be shared by
multiple people. The build czar is responsible for ensuring that the
next kits are clean, <em>i.e.</em>, it builds and runs cleanly on all
platforms. The status of all ACE+TAO+CIAO+DAnCE builds is tracked automatically
A comprehensive summary of the build czar's role is available <A HREF="bczar/bczar.html">here</A>.
This role is briefly summarized below:<p>
<li>Remind people to check build logs. Developers are still
responsible for verifying that their changes are clean.
<li>Trigger other developers to fix problems caused by compilation errors. All
problems should be fixed by the developers who caused them. The
build czar should help track down the guilty parties.
<li>Freeze the source repository when it's decided to no more
non-critical changes will be accepted for the next kits.
The build czar has the final say over when the freeze is
implemented. The tendency to implement a freeze sooner than
later is intentional, desirable, beneficial, and the "Right Thing"[TM]
<li>Verifies that the final round of builds/tests are clean.
<li>Creates the kits.
<li>Unfreezes the source repository.
<li>Sends email to appropriate news groups announcing the new kits.
<li>Passes the mantle on to the next build czar.<p>
If another developer interferes with the build czar's duties, the
build czar has the unilateral authority to pass the mantle to the
violator. This is also intentional, desirable, beneficial, and the
Right Thing[TM] to do.<p>
<H3>The ACE+TAO+CIAO+DAnCE Release Process</H3>
Minor releases of ACE+TAO+CIAO+DAnCE occur periodically, typically twice a
year. Minor releases have two-digit numbers, <EM>e.g.,</EM> 5.3.
Major releases are released infrequently, typically once a year.
Major releases are 1-digit numbers, <EM>e.g.,</EM>5, that include
substantially new functionality. Both major and minor releases are
carefully tested on all platforms the ACE+TAO run on. In particular,
we do not put out major or minor releases of ACE+TAO+CIAO+DAnCE until all the
compilations and regression tests work successful on all the platform
we support. <P>
Between major/minor releases, we release micro releases periodically,
<EM>e.g.,</EM> 3-4 times per year, so that ACE+TAO+CIAO+DAnCE users can
download and test our latest work in progress. ACE+TAO+CIAO+DAnCE micro
release kits have three-digit numbers, <EM>e.g.,</EM> 5.3.1. Micro
releases often contain important fixes that aren't in the major/minor
releases and will compile cleanly and pass most tests on most
platforms. They are not, however, necessarily concerned with ensuring
API compatibilities between micro releases, <EM>e.g.,</EM> new
features may be changed or removed between the micro releases. <P>
<H3>Contributions from the Open-Source Community</H3>
Over the years, ACE+TAO+CIAO have benefited significantly from
contributions by <A
of developers in the open-source community. To avoid fragmentation of
the code base, by submitting comments, suggestions, code, code
snippets, techniques (including that of usage) and algorithms
(collectively ``Submissions''), submitters acknowledge that they have
the right to do so, that any such Submissions are given freely and
unreservedly, and that they waive any claims to copyright or
ownership. In addition, submitters acknowledge that any such
Submission might become part of the copyright maintained on the
overall body of code that comprises the open-source DOC Group
software. By making a Submission, submitter agree to these terms.
Moreover, submitters acknowledge that the incorporation or
modification of such Submissions is entirely at the discretion of the
moderators of the open-source DOC software projects or their
<!--#echo var="LAST_MODIFIED" -->.<p>
Back to <A HREF="index.html">ACE Documentation Home</A>.