Version Compatibility and Support Matrix
This page was created to answer 1 question…
What versions of Apache Geode and Pivotal GemFire is Spring Data for Apache Geode and Pivotal GemFire (SDG) built on?
In addition to answering this question, among many others, this document will also explain:
-
Spring Data & Apache Geode/Pivotal GemFire Versioning
-
Release Cadence Mismatch
-
Compatibility and the Effects of Release Cadence
-
Difference between Compatibility & Support
-
Importance of Version Numbers and their relationship to both upstream & downstream dependencies, relative to Spring Data
Please post questions on StackOverflow for anything you think is missing, incorrect or ambiguous.
DISCLAIMER: This document is a work-in-progress (WIP) and currently under review. This document also does NOT represent a legally binding contract between you, your company and Pivotal Software, Inc. / VMWare, Inc. The statements are also subject to change at anytime.
|
Note
|
This page will be replacing the old Spring Data for Pivotal GemFire Version Compatibility Matrix. |
| Acronym | Definition |
|---|---|
SD |
Spring Data |
SDG |
Spring Data for Apache Geode and/or Pivotal GemFire |
The overview provides a quick summary of the sections that follow starting with the "Support Matrix".
After the "Support Matrix", you will find the "Compatibility Matrix". Keep in mind that "support" and "compatibility" are not the same thing!
This "Support Matrix" specifies the "supported" versions of Spring Data for Apache Geode & Pivotal GemFire.
By "support" we mean that SDG is "guaranteed" to work with the versions of Apache Geode & Pivotal GemFire declared in the "Historical & Official Support Matrices". This "guarantee" does not apply to the "Compatibility Matrix".
If a feature is missing, a function is broken, a CVE is found, or if any behavior of Apache Geode or Pivotal GemFire in a Spring context is not correct, then we will take action to fix the issue until the problem is resolved, meaning either a fix as been made or a workaround is provided.
All changes (missing features, minor enhancements, bug fixes, CVEs, etc) that are possible to resolve are only made in the next development iteration (e.g. 2.3.0.M3 if 2.3.0.M2 is current, or 2.3.0.RC2 if 2.3.0.RC1 is current) or service release (e.g. 2.2.5.RELEASE if 2.2.4.RELEASE is current).
|
Important
|
Not all issues with Apache Geode or Pivotal GemFire in a Spring context are Spring issues. In many cases, these issues can be reproduced with no Spring bits present at all, simply by using the Apache Geode or Pivotal GemFire API! It is very important to establish where the root cause of a problem occurs for the proper and most efficient resolution of your problem. |
|
Important
|
If a problem is proven to be caused by Spring (HINT: test(s)), then you must be able to reproduce the problem using the latest patch version of SDG in your "supported" major.minor version. For example, if you are using SDG Moore/2.2, then you must be able to reproduce the problem with the latest patch version of SDG Moore/2.2. If 2.2.4.RELEASE is the latest release of SDG Moore/2.2 and you are using less than 2.2.4.RELEASE (e.g. 2.2.3.RELEASE, or earlier), then you must upgrade and test with the latest patch version before reporting your issue.
|
| SDG | Latest | SD Release Train | Spring Framework | Apache Geode | Pivotal GemFire |
|---|---|---|---|---|---|
1.0.x |
1.0.1.RELEASE |
NA |
3.0.x.RELEASE |
NA |
|
1.1.x |
1.1.2.RELEASE |
NA |
3.1.x.RELEASE |
NA |
|
1.2.x |
1.2.2.RELEASE |
NA |
3.1.x.RELEASE |
NA |
|
1.3.x |
1.3.4.RELEASE |
NA |
3.2.x.RELEASE |
NA |
|
1.4.x |
1.4.6.RELEASE |
3.2.x.RELEASE |
NA |
||
1.5.x |
1.5.4.RELEASE |
4.0.x.RELEASE |
NA |
||
1.6.x |
1.6.2.RELEASE |
4.0.x.RELEASE |
NA |
||
1.7.x |
1.7.6.RELEASE |
4.1.x.RELEASE |
NA |
||
1.8.x |
1.8.11.RELEASE |
4.2.x.RELEASE |
NA |
||
1.9.x |
1.9.23.RELEASE |
4.3.x.RELEASE |
NA |
||
2.0.x |
2.0.14.RELEASE |
5.0.x.RELEASE |
No version of Spring Data for Apache Geode or Pivotal GemFire (SDG) nor any version of Apache Geode or Pivotal GemFire in the "Historical Support Matrix" above is currently supported. All SDG, Apache Geode and Pivotal GemFire versions have reached their End-of-Life (EOL).
|
Warning
|
If you are using one of these product versions, you should upgrade immediately! See the Official Support Matrix below. |
|
Note
|
Spring Data for Apache Geode & Pivotal GemFire (SDG) does not have a Spring Data (SD) Release Train association/version prior to SDG 1.4 since SDG was not part of the SD Release Train from 1.0.x to 1.3.x. It was a significant effort to incorporate SDG into the SD Release Train. It also means that you will experience both guarantees as well as consequences of this association, which are explained further below.
|
|
Note
|
Spring Data for Apache Geode (SDG) was not "officially supported" by Spring Data (SD) prior to SD Kay/2.0. At, or around this time, when SD Kay/2.0 went GA (Oct 2017), Apache Geode was just about to become a Top-Level Project (TLP) in the Apache Software Foundation (ASF). |
| SDG | Latest | SD Release Train | EOL | Spring Framework | Apache Geode | Pivotal GemFire |
|---|---|---|---|---|---|---|
2.1.x |
|
~October 2020 |
5.1.x.RELEASE |
|||
2.1.x |
|
~October 2020 |
5.1.x.RELEASE |
|||
2.2.x |
|
~March 2021 |
5.2.x.RELEASE |
|||
2.2.x |
|
~March 2021 |
5.2.x.RELEASE |
|||
2.3.x |
|
~May 2021 |
5.2.x.RELEASE |
|||
2.3.x |
|
~May 2021 |
5.2.x.RELEASE |
|
Warning
|
Apache Geode 1.6.x and Pivotal GemFire 9.5.x are no longer supported! If you are using Spring Data for Apache Geode or Pivotal GemFire (SDG) Lovelace/2.1.x, which are based on Apache Geode 1.6.0 and Pivotal GemFire 9.5.4 respectively, then we highly recommend you to upgrade to Spring Data (SD) Moore using the latest SDG Moore/2.2.x version. SDG Moore/2.2 is based on Apache Geode 1.9 and Pivotal GemFire 9.8, respectively. |
|
Caution
|
Spring Data Modules (e.g. SDG) and Release Trains (e.g. Lovelace) may have different support cycles than either Apache Geode or Pivotal GemFire itself. While these support cycles overlap it is possible and likely that 1 may end before the other. For instance, Apache Geode 1.6 and Pivotal GemFire 9.5 have already reached their EOL (i.e. Apache Geode 1.6 is no longer available from the website and Pivotal GemFire is no longer available in PivNet for download, which generally implies these versions are no longer supported), yet SDG Lovelace/2.1.x is still in support until ~October 2020. While SDG outlasted either Apache Geode or Pivotal GemFire in this case, the opposite situation can happen as well. Generally, you should take this to mean that your support is now limited and you are also strongly recommended to upgrade ASAP. While no more changes will be back ported if the SD Release Train reaches EOL, on the same note, very few if any changes will be back ported to a still supported SD Release Train (e.g. Lovelace/2.1.x) when the underlying data store modules (i.e. Apache Geode & Pivotal GemFire) are no longer supported. |
Spring Data (SD) Release Trains and Modules generally have a 18 month support cycle from the moment the first GA version of a specific SD Release Train occurs. This means 18 months from a major.minor.0.RELEASE (e.g. 2.1.0.RELEASE, referred to as Lovelace-RELEASE), which is considered the first GA version of the major.minor version (e.g. 2.1).
After the first GA version of a major.minor (e.g. 2.1), the support clock starts ticking and a series of service releases (a.k.a. maintenance versions or patches) to the major.minor version occur over the next 18 months.
For example, this is symbolized as Lovelace-SR15 or 2.1.15.RELEASE, which is the 15th patch, maintenance version, or service release of Spring Data Lovelace/2.1 since the first GA version (i.e. Lovelace-RELEASE or 2.1.0.RELEASE). These patches will continue roughly every 6 to 8 weeks until EOL occurs.
| SDG | Geode 1.6.0
|
Geode 1.7.0
|
Geode 1.8.0
|
Geode 1.9.2
|
Geode 1.10.0
|
Geode 1.11.0
|
Geode 1.12.0
|
|---|---|---|---|---|---|---|---|
|
NA |
NA |
NA |
NA |
|||
|
NA |
NA |
NA |
NA |
|||
|
NA |
NA |
NA |
NA |
NA |
NA |
| SDG | GemFire 9.5.4
|
GemFire 9.6.2
|
GemFire 9.7.6
|
GemFire 9.8.7
|
GemFire 9.9.1
|
GemFire 9.10.0
|
|---|---|---|---|---|---|---|
|
NA |
NA |
NA |
|||
|
NA |
NA |
NA |
NA |
||
|
NA |
NA |
NA |
NA |
NA |
…
The following section describes how Spring Data Modules and Apache Geode / Pivotal GemFire versions are determined.
Spring Data uses symbolic versions in addition to closely following semantic versioning.
Spring Data (SD) progresses in a series of "Release Trains". Each SD Release Train is "symbolically" named after a notorious computer scientist (e.g. …, Lovelace, Moore, Neumann, …). However, the SD Release Train naming conventions are much more than a fancy name.
The SD Release Train contains a set of Spring Data Modules (see "Main modules"), which are all based on a "common", core codebase rooted in Spring Data Commons. Even higher up, Spring Data is based on the core Spring Framework itself.
These SD Modules (i.e. "Main" modules; "Community" and "Related" modules are not part of the SD Release Train) all release together in harmony as part of the SD Release Train. The SD Modules are tested to ensure that they all work together in conjunction with each other when a user depends on the "symbolic" Spring Data version in his/her Spring application dependencies. This is very important since, after all, it is common for users to be using multiple SD Modules (e.g. Apache Geode with JDBC or JPA, i.e. with a RDBMS) together in a single Spring application. Clearly, it would be problematic if SD JDBC and SD for Apache Geode depended on and used different versions of Spring Data Commons or the core Spring Framework!
In addition to these "upstream" dependencies, there are also "downstream" dependencies from Spring Data, which can have consequences as well, and we will cover this concern in a later section.
<dependencyManagement>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-releasetrain</artifactId>
<version>Moore-SR4</version>
<scope>import</scope>
<type>pom</type>
<dependency>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jdbc</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-geode</artifactId>
</dependency>
</dependencies>
This example highlights that value of declaring a <dependencyManagement> section and importing the Spring Data BOM. You don’t need to specify or even know the versions of the individual SD Modules (e.g. SD JDBC, SDG) that your Spring application is using. This is helpful because the individual SD Modules (e.g. SD JDBC, SDG) may be at different major.minor versions within the SD Release Train. And, in this case, they are!
The point is, when using the Spring Data BOM, you don’t have to care about individual SD Module versions. The BOM handles that for you. You only need to depend on the Spring Data BOM (or alternatively, Spring Boot’s Dependency Management BOM) in your Spring application Maven POM (or Gradle build) file and know that you will have compatible SD Modules all built and tested on the same common, core codebase, which means they will all work together.
The fact of the matter is, versions are going to be different, even within the Spring Data project portfolio itself, because each SD Module has come into existence at different points in time. This is also what makes Spring Boot’s Dependency Management BOM so important and powerful since it curates and harmonizes in a thoroughly tested manner, not only the wider Spring portfolio, but also 3rd party Java libraries typically used by your Spring/Java applications as well (e.g. like logging). This ensures that those Java libs all work with your Spring applications in conjunction with the Spring bits, which use some of those same 3rd party Java libraries (e.g. SLF4J) without incident.
Spring Data encompasses much more than simply the "Main modules". Also see the "Community modules" and "Related modules" on the Spring Data project page at spring.io[https://spring.io]. Again, SD "Community" and "Related" modules are not part of the SD Release Train.
Now that we have beaten this dead horse enough, let’s move forward.
Not only does Spring Data (SD) use symbolic versions for, and to group, releases in the SD Release Train, SD also uses semantic versioning, expressed as a major.minor.patch version.
For example, SDG Moore-SR4 is SDG 2.2.4.RELEASE.
Technically, even with "semantic, numbered versioning", the Spring Data Team also combines major.minor.patch version numbers with Milestones (e.g. M1), Release Candidates (e.g. RC3) and GA (i.e. RELEASE) version qualifiers.
Major Minor version numbers (e.g. SDG 2.2.4.RELEASE) progress as you would expect, remaining generally compatible across minor versions (e.g. 2.0.x, 2.1.x, 2.2.x). Of course, the underlying data store must also be compatible across minor version numbers. SD minor versions cannot be compatible if the data store is not compatible across minor versions!
The patch version (a.k.a. "maintenance" version; the Spring Data Team calls them "service releases") only occur after a SD Release Train and the individual SD Modules contained in the SD Release Train reaches GA, that is, when the SD Modules reach version major.minor.0.RELEASE (e.g. SDG 2.2.0.RELEASE).
The RELEASE version qualifier is only used for the first GA version of the major.minor version and subsequent service releases (e.g. SDG 2.2.4.RELEASE; This means there have been 4 service releases, or patches, to the 2.2.0.RELEASE, the first GA version of SDG 2.2).
Before the GA release of a new major.minor version occurs, the Spring Data Release Train progresses through a series of 1 or more Milestones, then Release Candidate(s) and finally, the arrives at its first GA version, approximately 6 months later from the initial major.minor.0 build snapshot.
For example, SDG x.y.z.BUILD-SNAPSHOT to x.y.0.M1, x.y.0.M2, x.y.0.RC1 and finally, x.y.0.RELEASE is ~6 months. x.y.1-N.RELEASE (or N service releases of the `x.y.0.RELEASE/GA version) occur over a duration of 18 months.
The number of Milestones depends on the amount of scope the Spring Data Team has determined for a given SD Release Train. This varies from 1 SD Release Train to another Release Train.
For instance, SD Ingalls/1.x (e.g. SDG 1.9.x) only had 1 Milestone whereas SD Kay (e.g. SDG 2.0.x) had 4 Milestones, prior to their final GA releases.
The Spring Data Team prefers more frequent releases (Milestones) leading up to a final GA if the new features and enhancements are reasonably involved and we need to garner more feedback from our users on both direction and development (e.g. Think SD Reactive Repositories built on Project Reactor introduced in SD Kay/2.0 combined with the core Spring Framework’s new JDK 8 baseline as of 5.0, upon which SD Kay/2.0 was based; 2 very significant changes there).
Still, SD releases are time boxed as much as possible so users can expect a predictable release cadence, particularly to plan for upgrades given each SD Release Train has a general 18 month support cycle (hence "service releases) from the first GA.
While Milestones occur during ongoing development work of new features and enhancements, Spring Data Release Candidates are geared towards stabilizing the major.minor version. This generally means only fixes for bugs and CVEs. We may have 1 or more Release Candidates, roughly spaced a couple weeks apart, to lock down the release leading up to the final GA for the major.minor version.
Then, the GA version, or first "official" release of the major.minor version occurs (e.g. SDG 2.2.0.RELEASE). After which, we proceed with series of service releases, or patches to that major.minor version (e.g. SDG 2.2.x). Recently, the number of service releases, or patches, more closely coincides with Spring Boot’s lifecycle.
For instance, Spring Data Moore/2.2 is pulled in downstream by Spring Boot 2.2 and we will continue to support SD Moore/2.2 with service releases / patches for as long as Spring Boot 2.2 is supported and patched. This does not always perfectly align, but is generally the accepted practice followed now by the Spring Data Team, and all Spring projects for that matter given Spring Boot is the preferred starting point for all things Spring.
Finally, it is also important to point out that SD Modules each independently builds and depends on their underlying data store. After all, Spring Data_ (SD) is a common abstraction for, and integration technology supporting many different data stores.
SD MongoDB depends on MongoDB, SD Redis depends on Redis, and of course, SD GemFire/Geode depend on Apache Geode and Pivotal GemFire, respectively. Once the SD Module major.minor version reaches Release Candidate status, we fix that SD Module major.minor version on whatever the latest underlying data store major.minor version is at that time.
For example, SDG Lovelace/2.1 is based on Apache Geode 1.6 and Pivotal GemFire 9.5, which were the latest major.minor versions of GemFire/Geode at that time. Also important to note is that Pivotal GemFire 9.5 is based on Apache Geode 1.6. It would not be logical if SDG Lovelace/2.1 was based on Apache Geode 1.9 and Pivotal GemFire 9.5 if the GemFire/Geode versions were not compatible! This applies equally the other way too, i.e. SDG Lovelace/2.1 based on Apache Geode 1.2 and Pivotal GemFire 9.5, which is not compatible!
To compare and contrast, SD Moore/2.2 is based on Apache Geode 1.9 and Pivotal GemFire 9.8. Pivotal GemFire 9.8 is based on Apache Geode 1.9. SD Kay/2.0 was based on Apache Geode 1.2 and Pivotal GemFire 9.1. Pivotal GemFire 9.1 was based on Apache Geode 1.2.
Once a SD Release Train and SD Modules are fixed, the SD Modules can only upgrade to patch versions of the underlying data store within service releases of the SD Release Train.
For example SDG Moore/2.2 is currently on Apache Geode 1.9.2 and Pivotal GemFire 9.8.6. It is not OK, however, for SDG Moore/2.2 to move to Apache Geode 1.10/1.11 and Pivotal GemFire 9.9, whatever is available after the first Release Candidate, or especially after GA in addition to subsequent service release versions.
More on this topic will be explained further below.
Apache Geode and Pivotal GemFire do not use "symbolic versions". Both simply use semantic versioning non-strictly speaking.
It is not advisable to change the underlying binaries of either Apache Geode or Pivotal GemFire for a particular Spring Data for Apache Geode or Pivotal GemFire version since GemFire/Geode API binary compatibility is not guaranteed. There have been known issues when switching the baseline bits.
For instance, changing the underlying Apache Geode or Pivotal GemFire binaries of SDG Lovelace/2.1, which is firmly based on Apache Geode 1.6 & Pivotal GemFire 9.5, to Apache Geode 1.7, 1.8 or later and Pivotal GemFire 9.6, 9.7 or later is not guaranteed to work in all cases.
With regards to semantic versioning, users should be aware that not all minor enhancements nor bug fixes are back ported to previous, still supported, versions of Apache Geode and Pivotal GemFire. In many cases, users are required to upgrade. This can pose serious challenges when it comes to Spring Data’s compatibility for Apache Geode or Pivotal GemFire.
Additional technical details will be provided further below.
…