Reference Distribution
Each release can be thought of as Reference Distribution of CORD that packages the Reference Platform with a collection of Reference Solutions, bundled with a build system that can be used to install CORD on a set of target systems (e.g., a physical POD). The CORD Technical Steering Team (TST) decides what gets included in each Reference Distribution, and while there is just one such distribution today, we anticipate there might eventually be others (just as for Linux). For a more complete picture of larger CORD landscape, read Defining CORD.
Note that through the first three releases of CORD (Creamy-Vegetable, Mysterious-Decision, and Dangerous-Addition) the platform has changed rapidly, and as a consequence, we often conflate the platform version number and the release number (e.g., 3.0.0 for Dangerous-Addition). We expect the platform to stabilize as of the next release (Shared-Delusion), so going forward, these two should start to progress independently.
Release Cycle
CORD is on a four-month release cadence, with releases planned for February 15th, June 15th, and October 15th of each year. Development within each four-month release cycle occurs as a series of sprints, each averaging about 3 weeks. A four-month release cycle results in six 2-3 week sprints.
At the beginning of each release period, the TST schedules a set of planning meetings, the end result of which is a prioritized list of Features that the community will work on during the release period. Feature freeze occurs on the last day of the next to last sprint, requiring that all code intended for the target release be reviewed and merged by this date. The last sprint is considered the hardening sprint and should focus on fixing defects and documenting features. Support branches for the release should be created at the beginning of this sprint, leaving master open for new features to be developed. Release candidates are then generated based off of the support branch, and upon agreement that all critical defects are addressed and successful feature/system/stress/performance testing completed, an official release is announced.
More information about CORD practices for release planning, sprint planning, and other agile engineering processes can be found in a companion page: What Every Developer Should Know.
Release Branching, Versioning and Tags
- Master branch: Main development will happen on the master branch. This is the latest and greatest branch. It is expected to always be "stable" and "deployable," but it may change rapidly.
- Maintenance branch: This is the long-term maintenance branch per release.
- Development branches: These are branches created for lengthy and/or involved feature development that could destabilize master. Development branches can also be created for maintenance branches, for example, to complete a service release (see below). Development should never happen in a maintenance branch.
Each CORD release has the following version format: <major>.<minor>.<revision>
- Either the <major> or the <minor> version will be incremented for each release. The TST will decide whether to increment the major or minor number for the release. This decision will depend on a number of different factors such as incompatibility with existing APIs, etc. The <minor> version will be incremented for a service release, where new services are added or existing services enhance their feature sets.
- <revision> is incremented for a maintenance release to fix one or more bugs on the maintenance branch. Note: the revision number is optional when it is zero.
- 3.0.0-rc1: Release candidate for 3.0.0; rc1 is a temporary tag that gets cleaned up after 3.0.0 is tagged final.
- 3.0.0: Open source CORD release on May 15th, 2017.
- 3.0.1: Maintenance release for 3.0.0 (to fix critical bugs).
- 3.1.0: Service release for 3.0.0 (to include new services).
- ...
Maintenance Releases
CORD currently supports the past two releases. For example, the just released 3.0.0 and the previously released 2.0.0 are supported, but not 1.0.0. These maintenance releases typically include security patches and critical defects that are blocking deployments. Security patches will be proactively applied to the supported releases, whereas critical defects will be addressed by community request. The defects should have JIRA tickets associated with them. Releases will be done periodically, as needed. A release can be requested by the community by sending a request to the TST mailing list. Defects fixed in previous versions should be ported forward to all versions released since then, including master. For example, a fix in version 2.0 should be ported to 3.0, etc... and master. Module owners should assess the changes and drive the cherry-pick process.
Service Releases
CORD integrates a lot of components – a core platform, plus a set of services (e.g., vSG, vRouter) and a set of service profiles (M-CORD, R-CORD) that can be on-boarded with the platform. With TST approval, service releases can be cut to include additional services and service profiles in the release support branch. Service releases are supported on only the most recent support branch. For example, if the current support branch is 3.0, a 3.1.0 service release is permitted, but adding additional services to the 2.0 branch is not supported.
Support for service releases allows us to decouple platform releases from service and service profile releases, while keeping the full CORD distribution loosely in sync. Since services depend on the platform, it is difficult for service developers to upgrade their services to be compliant with the latest platform in time to make the standard CORD release schedule. An alternative would be a set of independent profile-specific releases, but that runs the risk of silo'ing the various service profiles, which diverges from the intent that CORD be able to support any meaningful combination of services (e.g., a multi-access edge deployment that is effectively a combined R+E+M-CORD configuration).
For example, the 3.0 version released in May might include only the R-CORD profile, with a 3.1.0 service release in August adding the A-CORD and E-CORD profiles (plus associated services) to the maintenance branch. This gives the A-CORD and E-CORD teams several weeks to upgrade their services to use the latest features in the 3.0 release of the platform. Service releases are an option for service developers. It is a goal, but not a requirement, that services and service profiles keep pace with the platform release cadence.
To be more specific about exactly what a service release implies, the set of services and service profiles included in a given release is exactly those specified in the repo manifest/default.xml file. Of these services and service profiles, each is classified by the TST as either Official or in Development, as reported on the Service Inventory page. A service release typically implies that the respective set of services have been promoted to Official status for the target platform. Because Official implies supported, a service upgrade effectively means a service has been added to the support branch.
Support for service releases is not necessarily a viable long-term strategy. Eventually, there will likely be multiple CORD Distributions, each packaging a different collection of services and service profiles with some version of the platform. Today, however, service releases provide a practical way to bundle platform releases with a viable set of services and service profiles.
Release Naming
During the development cycle and for easy identification post-release, each release is also identified by a "code" name in addition to the version. Release names are selected, by a vote of the CORD developers, from a set of host names auto-generated by the Metal-as-a-Service involved in installing CORD. People looking for a rationale explanation for this naming convention will be disappointed. Developers appreciate the Dadaism.
Cutting a Release
The step-by-step process for cutting a release is documented here.