Skip to end of metadata
Go to start of metadata


The Kuali Rice project provides the technical infrastructure for other Kauli Foundation software projects. Changes to the Rice project can have a significant impact on these other projects and, often times, their development efforts are very much interdependent as new features are added to Rice in support of these other projects.

The existing process of integrating code changes to the Rice project into other Kuali Projects has proven to be problematic. As a result, we are proposing a revised release plan for the Kuali Rice project. Based on three levels of releases, this new plan seeks to provide a mix of reliability, predictability and flexibility depending on the different development cycles and changing needs of the different constituencies.

New Release Plan

The Rice Project will deliver binary archives according to three different reliability grades. All releases are meant to reflect the state of the project code along a particular development path at a particular point in time. The main difference is the degree to which the code reflects a complete and fully tested set of release objectives.

  1. Official RELEASEs — Represent a complete and fully tested version of Kuali Rice as determined by the Kuali Rice Functional Advisory Committee, who are responsible for charting the course of Rice development. Official RELEASEs are delivered as and when identified functionality has been satisfactorily completed. They represent the canonical versions of Rice.
  2. MILESTONE releases — Represent intermediate work products that have been validated in a reasonable manner. There may be some known issues with a given MILESTONE but the objective is to keep those to a minimum. Unlike RELEASEs, MILESTONEs will be released according to a regular schedule. The schedule will grow more frequent as an Official RELEASE grows closer.
  3. SNAPSHOTs — Represent the active branch of development as of the previous 24 hours. SNAPSHOTs will have passed unit tests, but will not be verified against the integration test suite. As such, they are likely to contain some defects and should only be used with that in mind. SNAPSHOTs are a convenient way to track the latest version of the code base without having to checkout and build it yourself. These will most likely be used for internal development.

SNAPSHOT Releases — The Daily Build


A SNAPSHOT build will be run in the early afternoon.


The SNAPSHOT build will include: compilation; unit, functional and integration testing; code quality reporting (e.g. coverage); JavaDoc and Source Code packaging.

Release Criteria

The SNAPSHOT must pass all unit tests but will not be required to pass all integration and functional tests. If a check-in occurs that breaks the ability of the Maven build to run successfully (regardless of integration and functional testing) then whoever has committed must stop work and fix the build as quickly as possible.

MILESTONE Releases — Integration Testing


A MILESTONE release will be run on a predetermined scheduled date according to the project plan. Multiple MILESTONEs will be built during the typical release process. The MILESTONE will be run manually by the Configuration Manager (or delegate) based on a specified SVN revision derived from a valid SNAPSHOT release. This means that, as a MILESTONE approaches, the SNAPSHOT releases must receive increased scrutiny with respect to integration test success/failure.


The MILESTONE build process will be the same as the SNAPSHOT build process.

Release Criteria

In addition to passing all unit tests, the MILESTONE release must past an acceptable level of integration and functional tests. A MILESTONE release will only be published if all integration and functional tests are passed or if a majority vote is passed by the members of the Rice Core Development Team based upon input from downstream projects.

Official RELEASEs —


RELEASEs will be built based upon the Foundation schedule as documented according to the official project plan. The RELEASE will be run manually by the Configuration Manager (or delegate) based upon an SVN revision number derived from a valid MILESTONE.


The RELEASE build process will include everything from the MILESTONE build process. In addition, the official documentation (docbook) will be generated and packaged, including official Release Notes. Also, the RELEASE will be published not only the appropriate Maven repositories but published to the Rice project homepage.

Release Criteria

A RELEASE will be published according to the acceptance criteria defined by the Rice Functional and Technical Committees. Ideally, this means no failing unit, functional or integration tests, in addition to all required functionality being fully implemented.

Open Questions

  • Stop-work policies
  • MILESTONE schedule impact
  • SNAPSHOT frequency: daily or continuous/per-checkin.
  • Version compatibility: run during MILESTONE or SNAPSHOT?


  1. Notification of MILESTONE releases should go to Rice Collab mailing list.

  2. Pain points from KC.

    1. Testing. KC would wait long periods (couple of months) before integrating updates. This could often incorporate lots of changes on the KC codebase. Started to integrate on a weekly basis to reduce the ongoing impact of these kinds of changes.
      • need to keep feature branches closely sync'd with main branch to prevent 'code bombs'
    2. Unit testing is inadequate in rice currently. KC's testers might identify some issues, and the issues get resolved. Is there a way to get a hotfix into a MILESTONE?
      • can we do this with a pre-milestone that gets issued to projects like KC for preview?