Understand Software Versions

Understanding the version numbers used by core, Ecosystem Packs (EEPs), EEP components, and patches can help you keep your software up to date and plan for upgrades.

HPE Ezmeral Data Fabric release versions generally follow the industry-standard <major>.<minor>.<maintenance> format, with a number representing each version. However, some data-fabric software products use different versioning formats. The following sections describe the characteristics of the various data-fabric versioning formats.

Core Versions

In HPE Ezmeral Data Fabric interfaces and documentation, core versions are expressed as a dot-separated string of numbers having two, three, or four places. For example:

A Change to This Version Typically Includes For Example
Core major version Significant new features and API changes that can introduce incompatibilities with the previous version. Release 6.x followed Release 5.2.x and added built-in security features, database features (secondary indexes), new APIs (Apache OJAI and Change Data Capture), a new EEP series (EEP 4.x), file-system enhancements, a new installer version, and a redesigned control system for monitoring the cluster.
Core minor version New features, bug fixes, and API changes that are sometimes incompatible with the previous version. Release 6.1 followed Release 6.0.1 and added security by default, a new ZooKeeper version, several new database features (Node.js and Python OJAI clients, complex type support, table metrics, support for the OJAI 3.0 API), a new installer version, a new EEP series (EEP 6.x), and storage tiers for the file system.
Core maintenance version Bug fixes only. This version typically does not introduce incompatibilities with the previous version.1 Release 5.2.2 followed maintenance releaseRelease 5.2.1 and introduced new EEPs, improvements to the disk space balancer tool, and a new Installer version, but did not include new features or API changes.
Core patch version An emergency bug fix (EBF) patch update, which provides bug fixes and does not introduce new features. Release 6.2.0.1 represents a patch, or EBF, on top of core release 6.2.0.0. Releases 6.2 and later add the fourth place as a patch version. Even though a core version is a string having two, three, or four places, most references to core versions in the data-fabric documentation use two or three places.

1Release 6.0.1 was an exception to this rule, adding REST API access to HPE Ezmeral Data Fabric Database JSON tables, event timestamp support for stream processing, streaming audit logs for the HPE Ezmeral Data Fabric File Store, and a new EEP series (EEP 5.x).

EEP Versions

In HPE Ezmeral Data Fabric interfaces and documentation, Ecosystem Pack (EEP) versions are expressed as a dot-separated string of numbers having two or three places. For example:

A Change to This EEP Version Typically Includes For Example
Major version A new EEP series that supports a new major, minor, or maintenance version of core. EEP Support and Lifecycle Status shows how EEP major versions change when new versions of core are introduced.
Minor version A significant change in features or APIs but no change in support for the current core version. EEPs 6.0.1 and 6.1.0 both support Release 6.1.0, but EEP 6.1.0 introduced new HPE Ezmeral Data Fabric Database features, such as the C# and Go OJAI clients, as well as new features for ecosystem components (Flume, Oozie, Tez, and Apache Kafka). EEP 6.2.0, which also supports Release 6.1.0, introduced new ecosystem component versions (Hue, Impala, Spark) and updated some components (Oozie and Hive).
Maintenance version Bug fixes only. EEP maintenance versions do not add new features or API changes and are backward compatible in the same EEP series. EEPs 5.0.3, 5.0.2, and 5.0.1 added bug fixes to the EEP 5.0.x line while preserving compatibility with Release 6.0.1.

About the Patch Version

Beginning with EEP 6.1.0, version numbers for some ecosystem components and data-fabric tools use a dot-separated string having four places instead of two or three places. For example:
  • Oozie 5.1.0.0
  • Installer 1.11.0.0

The fourth numeral represents the patch version. The patch version adds a unique descriptor for patches that can occur between releases. In future releases, as new versions of components are released, more components and tools will transition to a version string that includes the patch version.

How the Patch Version Increments

Beginning with EEP 6.2.0, the patch version can be a number in the range 0 through 999. For a newly released component, the patch version starts at 0 and increments by 1 when there is an EBF update. For example, if the EEP 6.1.0 general availability (GA) package version for Oozie is 5.1.0.0, the first bug-fix (EBF) package version will be Oozie 5.1.0.1. The next bug fix package version will be Oozie 5.1.0.2, and so on.

If the same version of a component is present in multiple EEPs, the patch version increments by 100 to provide a range of usable version numbers for future patches. This numbering scheme ensures that all patches have a unique version. The following table shows how the Oozie patch version increments for EEPs 6.1.0, 6.1.1, and 6.2.0:

EEP Oozie GA Version 1st Oozie Patch Version 2nd Oozie Patch Version
6.1.0 5.1.0.0 5.1.0.1 5.1.0.2
6.1.1 5.1.0.100 5.1.0.101 5.1.0.102
6.2.0 5.1.0.200 5.1.0.201 5.1.0.202

To obtain EBF patches, you must contact HPE Support. HPE Support makes EBF patch versions available for specific known issues. See Patches for Known Issues.

Maven Version Format

Beginning with EEP 6.2, the patch version also is present in Maven artifacts for components that use the four-place versioning. In addition, the Maven version format changes to include the associated EEP instead of the YYMM timestamp:

Old Maven format with YYMM timestamp: maprdb-spark-2.2.1-mapr-1803.jar

Maven format with EEP number: maprdb-spark-2.3.3.0-mapr-602.jar

Beginning with EEP 8.1.0, artifact naming changed again to remove mapr from the version string and replace it with eep. For example:

Maven format that replaces mapr with eep:1.4.13.200-eep-810

The Maven version increments in the same way that the patch version increments. This table shows how the Spark package version and Maven versions increment when new EBF patch versions become available:

EEP EEP 6.0.2 EEP 6.1.1 EEP 6.0.3* EEP 6.1.2*
Spark Package Version mapr-spark-2.3.3.0.<timestamp> mapr-spark-2.3.3.100.<timestamp> mapr-spark-2.3.3.200.<timestamp> mapr-spark-2.3.3.300.<timestamp>
Spark 1st EBF Package Version mapr-spark-2.3.3.1.<timestamp> mapr-spark-2.3.3.101.<timestamp> mapr-spark-2.3.3.201.<timestamp> mapr-spark-2.3.3.301.<timestamp>
Spark Maven Version 2.3.3.0-mapr-602 2.3.3.100-mapr-611 2.3.3.200-mapr-603 2.3.3.300-mapr-612
Spark 1st EBF Maven Version 2.3.3.1-mapr-602 2.3.3.101-mapr-611 2.3.3.201-mapr-603 2.3.3.301-mapr-612

*This release is not currently available and is included only for illustration purposes.

A patch release can trigger periodic updates to the Maven repository. You may notice patches in the sftp.mapr.com repository that are not updated in the Maven repository. This is normal. The Maven repository will be updated eventually. The latest patch versions are always propagated first to sftp.mapr.com. If you have questions about patches, contact your HPE support representative.