uPortal
uP2 Release Strategy
Last changed on Apr 14, 2005 by William G. Thompson, Jr.
This Release Strategy describes how uPortal versions are labeled, what kinds of builds are available, and a plan to move the project along a well defined path to deliver bug fixes, new features and enhancements in a timely fashion.
Version Numbering
uPortal versions are denoted using a triplet of integers: MAJOR.MINOR.PATCH. Each version represents improvements to prior releases in the form of bug fixes, enhancements and new features. The purpose of labeling versions this way is to communicate the kind of change that has happened between releases and some indication of the effort required to upgrade to a newer release. The three types of releases are:
- PATCH - a conservative incremental improvement that includes bug fixes, enhancements and new features and is absolutely backward compatible with previous PATCH releases of the same MINOR release. (i.e. 2.4.15 is a drop in replacement for 2.4.14, 2.4.13, 2.4.12, etc.)
- MINOR - an evolutionary incremental improvement that includes all PATCH release improvements along with fixes and enhancements that could not be accommodated without breaking backward compatibility.
- MAJOR - a revolutionary change accommodating sweeping architecture, approach, and implementation changes.
Upgrading to a PATCH release is painless (e.g. 2.4.1 -> 2.4.2) and all uPortal adopters are encouraged to stay current with the latest PATCH release.
Upgrading to a MINOR release may cause some pain (e.g. 2.4.1 -> 2.5.0). Upgrading to a MINOR release may require some planning and migration effort. uPortal adopters are encouraged to move to the latest minor release as appropriate.
Upgrading to a MAJOR version may cause a lot of pain (e.g. 2.5.0 -> 3.0). Moving to a MAJOR version may require significant planning and migration efforts. uPortal adopters are encouraged to be no more than a MAJOR release behind the current release.
Builds
uPortal has three types of builds; Milestone (M), Release Candidate (RC) and General Availability (GA) Each type of build represents the state of a particular release;
- Milestone represents a work in progress and typically contains a subset of features, bug fixes, issues, etc. targeted for a particular release. Periodic Milestone builds are useful to gauge the progress of a particular release and to get early feedback on new features and enhancements. (e.g. rel-2-4-1-M1, rel-2-4-1-M2, ...)
- Release Candidate represents a build that is feature complete for a particular version. Release Candidates signal the end of introducing new features on a partcular line of development and the beginning of a Quality Assurance cycle. (e.g. rel-2-5-0-RC1, rel-2-5-0-RC2, ...)
- General Availability is “as good as it gets” for a particular version. A GA build is the output of a testing cycle that vetted a particular Release Candidate by passing all available tests and meeting all functional and non-funtional requirements for particular version. (e.g. rel-2-5-0)
Marching Towards a Release
If all goes well the progress of any line of development will follow a well defined path that delivers increasing functionality and/or stability in the form of a General Availability release in a timely fashion.
There are generally two lines of development for any MAJOR release, HEAD and a patches branch. The HEAD is where MINOR releases are developed and labeled. The patches branch accommodates changes that qualify for a PATCH release and is where PATCH releases are labeled.
Each line of development will see a series of Milestone builds of increasing functionality/issue resolution marching towards a feature/issue-complete Release Candidate (RC1), which is followed by a series of RCs of increasing stability culminating in a final GA release, at which time the process begins again.
Each line of development will have a Release Engineer who is responsible for managing the release through the process, setting target dates for Release Candidates and building consensus for targetting issues for a particular version and cutting the final GA release.
From jasigch.princeton.edu:9000/display/UPC/uP2+Release+Strategy14 April 2005