I think LTS implies a lot of things I’m not sure about yet. I suggest we keep
the 1.9.x release line going to help “Spring Data for Apache Geode” on an as
needed basis and see how it goes.
Anthony
> On Sep 30, 2019, at 6:32 PM, John Blum wrote:
>
> 1 more thing...
>
> I am also not saying
1 more thing...
I am also not saying all Apache Geode LTS versions (e.g. 1.9) need to
perfectly align with the SD Release Train for which the SD Release Train is
based (e.g. SD Moore/2.2 <-> 1.9), release by release, especially given we
have quite a few service/patch releases per SD Release Train
Well, release durations are subjective to begin with. What makes a 3 month
cycle any better than a 6 month cycle or vice versa?
For one, I think it is very project dependent. Rather, SD strives to
achieve a predictable release cycle (i.e. fixed duration over X amount of
scope, e.g. every 6
I agree.
This is the most sensible way to achieve release alignment.
--
Mike Stolz
Principal Engineer, Pivotal Cloud Cache
Mobile: +1-631-835-4771
On Mon, Sep 30, 2019, 8:09 PM John Blum wrote:
> Put simply, from my perspective, I would like to see LTS versions of Apache
> Geode align with
I am curious, what is the primary reason for such a long release cycle for
Spring Data Geode?
Also curious, what kinds of fixes is SDG expecting to “keep out” by locking in
a particular minor release?
Perhaps a good question for Geode is, why do we increment the minor version on
every
Put simply, from my perspective, I would like to see LTS versions of Apache
Geode align with the *Spring Data* (*Release Trains*) support for Apache
Geode.
For example:
SDG Lovelace/2.1 is based on Apache Geode 1.6.x.
SDG Moore/2.2 is based on Apache Geode 1.9.x.
Therefore, both Apache Geode
Hi All,
It has come up a few times in recent weeks about the possibility of an LTS
version of Geode. Is this something the community would be interested in?
There are advantages and disadvantages to supporting an LTS. Some
advantages may include:
- Stable release for downstream projects
-
