Skip to end of metadata
Go to start of metadata

This roadmap shall outline the intended major and minor releases, along with assumed timeframes and expectations for delivering tier 1 and 2 enhancements. It will suggest tier 3 out of scope enhancements that other interested parties are encouraged to deliver within similar timeframes.

The roadmap and the release cycle are inter-dependent. In order to plan how functionality and technology are evolved in Rice, we need to understand what the release cycle will look like, and how it will relate to the releases of Kuali Applications (KFS, KS, KC, etc.).

Release Versioning Scheme

Versions of Kuali Rice shall follow a numerical scheme consisting of three parts separated by periods: Major.Minor.Patch

  • Major Versions are intended to be long-lived versions of the software that consist of numerous minor versions. The decision to create a new major version will be the result of the need for major changes that cannot be successfully implemented without breaking version compatibility. It is permitted that different major versions of the software will not be compatible with each other. Applications that are created in later versions of Rice may not be compatible with earlier major versions of Rice. However, a reasonable and well-documented upgrade path should still be made available from a previous major version of the software to it's next major version.
  • Minor Versions are where most of the new work on the software will be done. It is intended that different minor versions within the same major version should be compatible.
  • Patch Versions should be created to address security issues or bugs with an existing minor version release. Different patch versions within the same minor version should be fully compatible with each other.

The following graphic illustrates the relationship between the different version types.

Gliffy Zoom Zoom ReleaseCycle1

Release Lifespan

Each of the different types of Kuali Rice versions will have an expected lifespan which will help to determine how best to schedule roadmap items into a release.

Major Version Lifespan

As mentioned previously, a major version of Kuali Rice should represent large architectural changes or paradigm shifts which could result in changes that cause incompatibility with previous versions of the software. Efforts should be made to reduce this impact as much as possible. However, in order to allow for continued evolution of the Kuali Rice software, these types of changes will be necessary.

Additionally, a major version will likely be started in parallel with work happening on a previous major version. Subsequently, once a new major version is released, maintenance work will continue on the previous major version until it's end-of-life (see End-Of-Life below).

Because of the impact that major versions will have on existing applications, new major versions should be created only when necessary and should have a long lifespan.

Ideally, a new major version of Kuali Rice should not occur any more frequently then every 2-3 years.

Minor Version Lifespan

Minor versions will be where the majority of the new Kuali Rice work will happen. Generally, other Kuali applications will work to align their releases with a specific minor version of Rice. The goal for minor versions of Rice should be to maintain a relatively short release cycle in order to facilitate pushing out new functionality for Kuali applications or other implementers in a reasonable time line.

However, minor versions of the software will still need to go through a rigorous quality assurance cycle in order to ensure that the version is as stable as possible. This will require that sufficient time be allocated for this during the release cycle of the minor version.

Taking all of this into consideration, the Kuali Rice team should strive for minor version releases every 6-9 months.

Patch Version Lifespan

Patch versions are to be primarily used for bug fixes and security issues. At a minimum, the two most recent minor versions of Kuali Rice (within a specific major version) at any given time will continue to be maintained with patches.

Because of the bug fixing and security focus of patch releases, these should be released as often as needed.

Lifespan Summary

Major Versions: 2-3 years
Minor Versions: 6-9 months
Patch Versions: as needed

Relationship of Kuali Rice Releases to Kuali Application Releases

As mentioned previously, Kuali Applications (KFS, KC, KS, etc.) should attempt to align their release schedule with a specific minor release of Kuali Rice. They should then work with the roadmap committees to ensure that any Kuali Rice work that they require for their release be included in the roadmap and release planning for that version of Rice.

Ideally, the Kuali Rice work will be done in advance of the application work and be completed prior to the Kuali application's quality assurance period to allow time for the Kuali application to properly integrate and test the changes. In practice, this can be difficult to accomplish. However, this should be a goal of increasing importance as we continue to move Kuali Rice and the other Kuali applications forward.

The targeted version of Kuali Rice should be released to the public prior or in conjunction with the public release of the Kuali application software on which it is dependent.

End-Of-Life for Major Versions

In order to reduce the overhead of maintaining numerous old versions of the Kuali Rice software, an end-of-life policy will be implemented for older major versions.

A major version will reach it's end-of-life once two subsequent major versions have been released.

For example, Kuali Rice 1.x will reach it's end-of-life once Kuali Rice 3.0 is released.

During the intervening period, patches will continue to be made available when needed for the previous major version of the software.

Release Cycle

The Kuali Rice release cycle consists of a few distinct phases as outlined in the charter.

  1. Preparation and Planning
  2. Application & Technology Architecture
  3. Software Design and Development
  4. Software Testing and Configuration
  5. Software Release & Implementation Support
  6. Post-Release Support

Note that these phases are applicable to major and minor version work. Patch versions will be driven based on bug reports from the community and other Kuali applications and will happen during the "Post-Release Support" phase.

Pre-Release Versions

In order to allow for pre-release testing and upgrade planning by the community, Kuali Rice will provide early availability releases of the software to the public. Each of these "releases" will fall into one of three categories:

  1. Development Builds
  2. Milestone Releases
  3. Release Candidates

The implications of making these versions available early include:

  1. Licensing vigilance needs to be maintained in an ongoing fashion on the project. All licensing policies and procedures must be followed rigorously in order to prevent accidental release of code or binaries which are using improperly licensed code or libraries.
  2. Release notes and changelog documentation needs to be maintained and updated in parallel and in real-time to the development work. This will facilitate others being able to successfully work with the early releases and test them prior to the generally available packaged release and documentation.

Development Builds

The development process of Kuali Rice is backed by a continuous integration environment in which the software is continually built and automatically tested. This environment can be used to create development builds of the software for those that are interested in working with very early and possibly unstable versions of the software. The primary customers for these builds would be those in the community that might want to apply patches to their local implementation or the other Kuali applications which might be working with these development builds in parallel with development of their application.

Alternatively, the source code for the latest version will be publicly available at all times in source control for those that want to obtain a copy of it.

Milestone Releases

A milestone release will represent a point in time in the release and development cycle when a major set of enhancements or changes are completed. A minor version may only have one or two milestones while a new major version may have many more.

What constitutes the milestones for a particular version of Kuali Rice will be decided during the planning phase and will be based on the major roadmap items of which that release is composed. A milestone release should be partially stable such that those who want to begin working with it can. It should be accompanied by some documentation which gives interested parties the information they need to get started with it. However, it is not required that this documentation will be complete.

Generally speaking, each version should have at least one milestone release prior to the beginning of the Quality Assurance phase.

Release Candidates

A release candidate represents a version of the software with potential to be the final public release. The intention of making a release candidate available is to allow for those in the community to work with the software and report any bugs they may find. If there are no fatal bugs found with the release candidate within a specified period of time, then the version is ready for release. If fatal bugs are found, they will be fixed and a subsequent release candidate will be made available. A release candidate should be accompanied with a mostly complete set of documentation.

Ideally, each version of the software should only go through 1 or 2 release candidate versions prior to the generally available public release.

8 Comments

  1. Should the Release Cycles section also talk about how we will handle upgrade paths and also support of previous Rice releases?

    1. Jim, I've included some information on that in here. Let me know if you think it sufficiently communicates this information.

  2. What are tier 1 and tier 2 enhancements?  We should define these terms if they are being used in the roadmap document.

  3. From the Rice Charter (below).  I assume this section is where the Roadmap & Charter cross? 

    This functionality shall be grouped into 3 tiers according to agreed on development priorities. Tier 1 functionality includes enhancements to the core components being released in version
    1.0 that are critical and fundamental. Tier 2 functionality includes major components that are important to the Kuali Applications for addressing any gaps in middleware and application
    development needs; these may be large components that can be satisfied by an existing best of breed software product or contributions from Interested Parties.

    Tier 3 functionality includes components that the Kuali Rice Board and ARC have determined to be out of scope for this project. Kuali Commercial Affiliates, or commercial vendors, are
    encouraged to define projects to develop software modules and services that are currently outside the scope of this project, but complementary to the core.

    The ARC will create, publish and maintain a Kuali Rice Roadmap document which outlines the components and functionalities that are included in Tier 1, Tier 2 and which are out of scope in Tier 3. Development will progress towards delivering critical necessary new functionality by iterating within each tier according to development schedules determined by the ARC in conjunction with the Kuali Rice project team.

  4. I would like to address the comment "It is permitted that different major versions of the software will not be compatible with each other".  Should we update this wording to the following:

    "Applications or forms that are created in later versions of Rice may not be compatible with earlier major versions of Rice.  Application or forms created in earlier major versions of Rice can always be migrated to later versions."

     I think is is critical that we design a method whereby any University using Rice can painlessly upgrade to a new major version and not get 'frozen in time' to an old version because the upgrade path is too painful.

    In other companies I have worked at, we have found that putting effort in to desigining a process for adding new functionality in code that can always be added to older instances paid off huge in later major version development of the software.  As a very simple example, we would create a CASE statement that looked like:  If (form < v4.2) then NewFeature defaults are [XX,NN] - if (form < v5.5) then NewFeature defaults are [XX] else NewFeature is already defined...  Whenever a large feature edition was created, a new case was created and we only had to handle the update in a few places.

    1. I added some language to the first section which hopefully takes this into account. Let me know if this doesn't fully cover your concerns Emily.

  5. Does it make sense to work in some kind of "API Documentation Release" early in the release cycle? Is it feasible to release some level of documentation that will give the application projects something to plan around?

  6. I agree with Emily.  The end of life one year timeframe seems short and we probably need to have a larger discussion on what is the correct timeframe.  We might want to consider what is involved (investment) for an institution to upgrade to a new release and then back into what is a reasonable cost for the upgrade.  Deferring an upgrade allows a smaller average cost per year for the institution.  It also allows for other institutional projects to be factored into the timeframe.  A one year timeframe is short and will force institutions to do an upgrade that they might not want to make in a specific time period.