I agree with Robert that we should release based on features that go in.
I am not sure if Apache Kafka & Spark are a good reference for GEODE.
These tools were evolving rapidly in the last couple of years and frequent
releases would be good for a growing community.
Should we do a patch release ev
I have found it refreshing that the geode released cadence has been based
on features being done, rather than a set schedule.
I come from an environment where we had quarterly releases and monthly
patches to all supported previous releases, and I can tell you that it
became a grind. That being sa
+1 for scheduled releases and cutting the branch one month prior to
release. Given the time it took to fully root out, classify, and solve
issues with this 1.7 release, I think a month is the right amount of time
between cutting the branch and releasing. If it ends up being too much or
too little,
Anil, releasing every 3 months should give us 3 months of dev work. Don't
forget that there will be one month during which the next release is
already cut, but the vast majority of the work is going to the release
after that. So while we cut 1.7 one month ago and release 1.7 today, we
already have
If I remember from earlier discussion; the plan was to deliver a release
once 3 months. But from the past release history we had difficulty in
achieving that, either the features are not completely ready or the
bug-fixes have taken more time. We need verify what is right for Apache
Geode, 3, 4 or 6
Currently the default value for this parameter covers the default locator
and server port values. As a result of this, when launching a locator and
then a server on the same system using gfsh, it's possible to see the
server fail because the locator has already bound the default server
socket. We
---
Spring Data GemFire > Nightly-ApacheGeode > #1060 was successful.
---
Scheduled
2458 tests in total.
https://build.spring.io/browse/SGF-NAG-1060/
--
Thi
+1 on the scheduled release and also on one month prior to release we cut
the branch.
@Dan I feel keeping a one month will give a very comfortable time frame to
test + retest the release branch and we will be releasing a stable release
candidate.
For 1.7.0, it did take a month from cutting the br
+1 I definitely like the idea of scheduled releases.
I wonder if cutting the release branch a month ahead of time is overkill,
but I guess we do seem to keep finding issues after the branch is cut.
-Dan
On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann
wrote:
> Hi everyone,
>
> I want to propos
By ClassName I meant the name of the offending class, not a class named
ClassName. Sorry for the confusion there.
You're hitting a failure in a test that ensures that classes in
sanctioned-geode-core-serializables.txt can be serialized and
deserialized. The serialization filter is objecting
It's possible that I ran build/precheckin with a different version of Java.
Is it possible that would change the bits that
AnalyzeSerializablesJUnitTestBase is looking at and cause an unexpected
failure?
On Thu, Oct 4, 2018 at 1:24 PM, Kirk Lund wrote:
> But I didn't add or touch the class Class
But I didn't add or touch the class ClassName -- according to git log,
Jinmei and Patrick created it in the following commit on 1/29/18 -- I
haven't touched this at all on my branch:
GEODE-3915: use ClassName type for cache-loader, writer and listeners
(#1327)
* GEODE-3915: use ClassName type for
Hi everyone,
I want to propose shipping Geode on a regular cadence. My concrete proposal
is to ship Geode every 3 months on the first weekday. To make sure we hit
that date we would cut the release 1 months prior to that day.
*Why?*
Knowing on what day the release will get cut and on what day we
Sai and I noticed that the Acceptance style dunit tests that are starting
up locators in vm0 are generating a bunch of log statements about "Unknown
DataSerializableFixedID: 2145" and this looks wrong in several ways. I
reviewed it with Darrel and neither of us are familiar with TcpServer or
with W
It looks like your region attributes contain an instance of a class that
isn't in sanctioned-geode-core-serializables.txt. It's also possible
that you added the class to that file but it didn't get properly copied
to the output directory, so you might check that too.
Output of this test shoul
---
Spring Data GemFire > Nightly-ApacheGeode > #1059 was successful (rerun once).
---
This build was rerun by John Blum.
2458 tests in total.
https://build.spri
The Apache Geode community is pleased to announce the availability of
Apache Geode 1.7.0.
Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high
17 matches
Mail list logo
