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 month
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 th
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 quarter
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 1.6
