Each release of a Blue Cedar product follows the versioning approach here. Compatible products do not generally have the same version number at the same time:
- Blue Cedar Policy Console
- Blue Cedar Integration Platform
- Mobile Client
- Virtual Appliance
- Major Release – Full product release with multiple significant new features. Will contain bug fixes. Major releases are normally accompanied by a high-visibility marketing launch.
- Minor Release – Product release comprised of minor new features and bug fixes.
- Maintenance Release – Full product release primarily to address product deficiencies. Contain fixes to issues in existing features and occasionally may contain minor new features. This release is primarily a roll up of all the hot fixes issued prior to the release. This will be different for product components.
- Hot Fix – Individual bug fix or product improvement delivered to customers. This is also the build number, and can identify what hot fixes have been applied for a customer instance. This number is different for product components. Hot fixes are generally given to specific customers who are facing issues. Once verified, general practice is to include these hot fixes in the next maintenance release for general availability.
- Build Number – Latest build number. This will be different for product components.
- General Availability (GA) – The main stable release that is supported by Blue Cedar engineering and support functions
- Beta – The latest stable release that is supported by Blue Cedar.
Software Versioning Approach
Our software releases are designated by the form W.X.Y where:
- W = Major Release
- X = Minor Release
- Y = Maintenance Release
Versions can be further specified as W.X.Y.Z where:
- Z = Build Number / Hot Fix
Release number changes
Direct upgrade path to be supported
W increments by 1. X is set to zero. Build number can be hidden and doesn’t need to be displayed. All components have the same major release number.
From previous Major release (including any minor releases associated with previous major release) to the current major release. Ex: From 4.1 to 5.0 or from 4.3 to 5.0, but not from 3.5 to 5.0
No backwards compatibility
Version compatibility between at least 2 of the services (appliance, Client, Platform)
Potential global system down time
Minor (weekly or biweekly, new features)
W does not change. X increments by 1. Build number can be hidden and doesn’t need to be displayed.
From any previous Minor or Maintenance release with the same Major release number to the current Minor release with the same Major release number. Ex: From 4.1 to 4.4, but not from 4.3 to 5.2
No breaking changes
No requirement for version compatibility within Minor version
Bug fixes (non breaking)
Potential system component down time
Maintenance (weekly or biweekly, bug fixes only)
W and X do not change. Y increments by 1. Build number can be hidden and doesn’t need to be displayed. Products generally have different Y number.
From any previous Minor or Maintenance release with the same Major release number to the current Maintenance release with the same Major release number. Ex: From 4.1 (or 4.1.1) to 4.4.1, but not from 4.3.1 to 5.2.2
No breaking changes
No recertification requirement; no algorithmic changes referencing federally imposed standards requirements.
Potential intra-system component down time
W, X, and Y do not change. Z is the build number, which will be used to refer to the hot fix.
New hot fix includes previous fixes for the same binary.
Hot fix version number will always increment (independent between release tracks)
No down time
Client app upgrade recommendation
Software Version Support Policy
Our standard practice will be to provide support and maintenance on the following releases:
- Beta - The latest major or minor release of the software. (Beta)
- GA - The immediately preceding major or minor release of the software.
- If you encounter a bug in a version of the software that is not the latest release, we may require you to upgrade to a specified later version to fix the issue.