Release Practices

Sakai's release practices need to evolve in order to meet our community's goals for 2008:

• Create the highest quality core software.

• Seek to engage new members of the community.

How it should evolve was the subject of much on-line discussion leading up to the Newport Beach 9th Sakai Conference, further discussion in conference sessions and BOFs, and resulted in three main options being presented to the community for additional discussion through 7 January 2008. The culmination of these discussions are reflected in the proposed release practice guidelines below. Feedback on this proposal is welcome through the end of January 2008, at which time we plan to begin migrating to this practice as we continue forward, unless serious, significant objections are raised.

Proposed Release Practice Guidelines

The community discussion identified two different, but not opposing opinions, and the proposal below strives to satisfy both groups' needs:

• high-quality, easy to deploy and maintain software with long-term support, and

• frequent, easy access to new functionality

Proposal:

• Major Releases – Targeted at organizations for which a stable, long-term deployment is desired, and for which access to maintenance releases as a resource for bug fixes is critical.

  • Predominately driven by the completion of significant improvements and enhancements in Sakai; also includes all the limited improvements in functionality introduced in minor releases since the last major release.

  • Expected that such releases will occur approximately every twelve months.

  • Entire release tested through the coordinated activities of the QA Working Group and early adopters, culminating in an initial release after approximately four to six months of QA, beta, and release candidate tags. (For example, Sakai 2.5 was branched from trunk in October 2007, a beta2 tag is currently available, and the initial release is expected in February 2008.)

  • Bug fixes merged to the release's maintenance branch as appropriate.

  • Periodic tagging of maintenance releases from the maintenance branch, with QA on the maintenance release focused on the bug fixes incorporated.

  • The maintenance branch will be managed and maintenance releases provided for two years after the initial release (or longer, if there is sufficient community interest and resources).

• Minor Releases – Targeted at organizations who desire access to new functionality, and who have a higher tolerance for and ability to mitigate risk and short-term change.

  • Predominately driven by the readiness of a limited set of new features and functionality.

  • Expected that many such releases will occur between major releases, with a new minor release occurring roughly every one-to-three months.

  • Newly introduced functionality tested through the coordinated activities of the QA Working Group and early adopters, culminating in a release after approximately one month of QA, beta, and release candidate tags.

  • Maintenance branches (and maintenance releases) would be dependent on community volunteers.

    • Organizations that are responsible for the new functionality, and those that intend to use such releases in production, are likely to volunteer such resources.

    • If a particular minor release contains a key set of features, and comes at a convenient time of year, such that a large number of organizations deploy it, then it is very probable that those organizations will also be interested in contributing volunteers to maintain it over a long period of time.

• General Notes:

  • Trunk will no longer be treated as wild. Bug fixes and minor Tasks can continue to be done to trunk, however, major new functionality and significant enhancements should be developed in branches and merged back to trunk as appropriate.

    • We already have some experience with this through our recent practice of using Experimental Branches or "Jira" Branches for potentially significant changes.

    • From the Experimental Branches or "Jira" Branches description, this involves:

      Experimental Branches

  • There should be sufficient advance notice of new functionality so that it can be appropriately placed on a roadmap for a future major or minor release of Sakai. The sooner the better, however, features should be put forth for consideration no later than the Feature Freeze for a release.

    • A major release of Sakai would have a Feature Freeze two months before the code is frozen, branched from trunk, and QA begins.

    • A minor release of Sakai would have a Feature Freeze two weeks before the code is frozen, branched from trunk, and QA begins.

    • If new functionality fails to meet a release deadline, then an evaluation will be made to balance the benefits of sliding the deadline versus delaying the timely availability of other new functionality in the release. (Rescheduling new functionality to a later release will generally not significantly delay its availability, as the time period between minor releases can be short.)

  • If sufficient QA resources become available over time, then the scope of QA on maintenance releases and minor releases could certainly be expanded beyond focusing on the changes.

  • What does this mean for 2.6? 2.7? 2.8? ... 3.0?

    • We would immediately solicit suggestions for a limited set of new or enhanced functionality that folks are already working on or would like to get started on, and which could be completed in time for a 2.6 release in April/May 2008, a 2.7 release one to three months after, and so on; however, those time-frames are merely suggestions that need to be adapted to the functionalities' availability.

    • The next major release (3.0?) would likely be in early 2009 at the soonest, but again timing really depends on what folks are prepared to work on between now and then, and how significant of a change that work would imply for Sakai as a whole. If the changes are more of an incremental nature, rather than a re-architecting or re-factoring of major portions of Sakai, then it is likely that a 2.x version (perhaps 2.11?) will be the next major release. Either way it would include all the incremental functionality changes and bug fixes between 2.5 and then, subjected to full QA, and followed up with support for two-years.

  • What is a clear naming convention for easily distinguishing major/minor releases?

    • Do we increment major version number, the first number in a version's name (i.e., the "2" in 2.5.0), for every major release, regardless of how significant the changes are? Or, do we potentially have multiple major releases in the "2" series, such as 2.5.0, 2.11.0, etc., and only increment the major version number when there is sufficiently significant change?

    • Do we name each release separately from its version number, using themes to distinguish between major releases, regardless of how significant the changes are from the last major release? Each major release could introduce a theme and each minor release would be a variation on that theme; however, the change in theme would not be dependent on their being significant changes to warrant incrementing the major version number. For example, 2.5 would be Lambchop, 2.6 Porkloin, 2.7 Beefrib, 2.8 Turkeyleg, 2.9 Ostrichwing, ..., 2.11 would be Blackbird, 2.12 Sparrow, 2.13 Pigeon, 2.14 Heron, 2.15 Parrot, ..., 3.0 would be Oak, 3.1 Pine, 3.2 Maple, 3.3 Larch, and so on...

    • What are some good examples of how other software does this?

  • What is the impact on Feature Branches?

    • The need for Feature Branches is likely to be supplanted by the minor version releases.

    • The minor versions offer a better path for easy adoption and maintenance, as compared to individual projects' Feature Branches.

An example of what the release time-line might look like (and it might help to think of 2.11 as being 3.0 in the image below, or 2.5 as Lambchop and 2.11 as Parrot, as we hadn't really thought too much about naming conventions at the point this was drawn):

Open

For reference, here are the three general options that emerged from discussions at the end of the Newport Beach conference:

Option #1 - Focus is on adding functionality and less so on quality.

• Basically continuing with our current practices, as exemplified by the 2.5 release process.

• Only a maintenance branch for releases (e.g., 2.5.x, 2.6.x), no maintenance releases.

• A 2.6 with a only a small set of feature enhancements and QA'ed across the board, with an initial beta release in June 2008 and a final release in September 2008; a similarly-scoped 2.7 with a beta in November 2008 and final release in February 2009; and so on...

• This option really doesn't make things any easier than now for deployers.

Option #2 - Focus is on quality and less so on functionality.

• 2.5 maintenance releases through August 2009, scheduled based on availability of QA resources.

• A 2.6 in March/April 2009, with beta and release candidates prior to that for use by early adopters in their beginning-of-the-year semesters.

• Means deployers have to wait a long time for new functionality and there will likely be a lot of it at once, or be comfortable using Feature Branches in the interim.

Option #3 - A compromise focusing on both functionality and quality.

• Only a maintenance branch for 2.5, no maintenance releases.

• Minor releases (2.6, 2.7, etc.) multiple times a year that include only a small, limited, incremental set of feature enhancements; QA would be focused mostly on areas of change, not everything would be tested.

• A major release (3.0) in the future, when there a some big, broad-scope changes that need to be brought into the release, with sufficient lead-time to organize the QA effort required to fully test the distribution.

• This is sort of a "maintenance release" path for deployers, but brings functionality with it, which can complicate keeping help and training materials up-to-date.

Comments from past versions of this page