- v1.0.0-latest-prod
Minor and Patch releases can involve additive (rollback compatible) database schema changes.
If your process supports liquibase, the main changelog in the Broadleaf base service jar contains any liquibase scripted migration required (no drops). There are also optional drop changelogs (if applicable) that can be included in your application changelog and vetted after a completed upgrade.
If you require raw SQL migration, review generate-sql.
Changes to REST API will remain backward compatible. However, internal component methods with protected scope may have method signature changes from time to time and may cause compilation failure if overridden in your codebase. The fix for these situations should be evident and will be mentioned in the release notes as well.
While the database schema change risk is generally minimal (additive only), it is still useful to review update scripts (and optional drop scripts) before any upgrade to ascertain scope.
Indexes are specifically NOT applied during a liquibase upgrade, unless the target table is empty. This is to protect the database and application from locking behavior during index creation that could cause an outage. See show-indexes for instructions on how to review index creation statements. Consult with a DBA if you have specific questions about the impact of index creation on your system.
Any further instructions required for an individual upgrade will be provided in this document in the notes for the specific version.
To review the security related content for releases, visit Broadleaf Security. You will need your login credentials originally provided for accessing the Broadleaf nexus. Security fixes often involve dependency updates to remediate issues being tracked in external OSS components. It is worth considering adopting releases with security fixes (even Broadleaf Severity LOW) to avoid any possibility of transitive exposure in your codebase.
Third-party library security vulnerabilities are addressed as part of base dependency releases. These releases are generally able to be plugged into an installation via maven configuration without upgrading the rest of the codebase. The base dependency release cadence more closely follows our policy thresholds for SCA vulnerability remediation, and adheres to a separate lifecycle from our main release train. Note, release train releases will automatically reference the latest third party dependency release bom available at the time.
The governing principles for base dependency releases are as follows:
Broadleaf routinely scans for known third-party library CVEs.
Broadleaf evaluates CVEs for false positives regarding Broadleaf framework usage, which may preclude or delay individual third-party library update considerations.
Generally, a framework code change is not required in order to upgrade a third party library. This is the easiest form of upgrade and requires only maven configuration (no code changes) in order to reference the new base dependencies release. Refer to Base Dependencies Release Override for instructions on how to configure maven in your codebase to consume a target base dependencies release.
If a code change is required to consume one or more library updates, then instructions are included in the base dependencies release notes on how to introduce an extension in your codebase to make it compatible with the third-party library upgrade.
If a code change is required, and it is not feasible to instruct on how to extend the codebase to adopt, then the lightweight upgrade to the base dependencies release is not possible. Instead, a full upgrade to a new release train version referencing the target base dependencies version is required. If applicable, this will be noted in the base dependencies release notes.
Broadleaf won’t be able to predict customizations you may have in your codebase that leverage one or more of the upgraded third-party libraries in an incompatible way. Therefore, it is recommended that any upgrade to a new base dependencies version be treated cautiously and go through a regular regimen of compilation, CI, and/or smoke testing to confirm stability.
Release notes regarding base dependency releases are detailed at Broadleaf Security.
The cadence will not necessarily be uniform. Rather, it will align with fulfillment of the SLAs. The shortest SLA is for CRITICAL, which is 7 days. If there are no CRITICAL issues, then it’s possible the releases will be less frequent in accordance with the diminishing timeline requirements. However, regardless of issue severity mix, base dependency releases will be delivered no less frequently than monthly, unless the base dependency is already being released as part of a standard release train release within that timeframe.
Broadleaf also references several third party container images as part of the application runtime stack. These are applications that provide supporting functionality, but are not under the control of Broadleaf.
Generally, this includes: Solr, Kafka (optional), and Zookeeper.
We routinely scan these images for both Linux and Java OSS vulnerabilities.
Since we do not control the source and release for these platforms, any SLA for pointing to new versions with known vulnerability remediations is "best effort".
Generally, the cadence for review of third party container image remediation status is monthly.
Review involves testing and confirmation with the latest vendor release (if available), followed by referencing known fixed CVEs in the security release notes at Broadleaf Security.
If your deployment uses the same images we reference in the security release notes, you may use the new image versions in your installation’s configuration.
As with any component change, you should smoke test your application with any changes before deploying to production.