I believe that a backwards compatibility framework is required. Even if just to confirm the compatibility between supported Geode versions.

If this framework were to be used/extended by any user of the Geode ecosystem, then it becomes their responsibility to maintain that extension.

--Udo


On 7/10/2016 3:31 AM, Mark Bretl wrote:
-1 for this

I do understand the intent and reason behind this, however, in addition to
the reasons Anthony provided, I do not believe this community should carry
the burden of testing compatibility with proprietary/commercial software.
Even though Geode has its history in GemFire, I can only see the community
supporting official Geode releases. It would set a bad precedent to allow
for any part of the Geode code ( source or test ) to depend on any
commercial code.

If any company wants to make sure their software works with Geode, it is
their responsibility.

My $.02,

--Mark

On Thu, Oct 6, 2016 at 9:12 AM, Bruce Schuchardt <bschucha...@pivotal.io>
wrote:

Yes, dist.gemstone.com.


Le 10/6/2016 à 9:08 AM, Dick Cavender a écrit :

Only on initial setup/access to repo.pivotal.io is the EULA acceptance
required. After that you should be able to pull from any repo there without
interaction but you will need to provide the creds as part of the pull.

Are you instead using dist.gemstone.com for the older jars which is the
original repo that lives in the spring s3 repo


On 10/6/2016 7:48 AM, Bruce Schuchardt wrote:

Thanks Anthony.

I thought there was some interest in supporting old GemFire clients and
WAN.  Is there no way to download it without a login/EULA?  I'm currently
using a different repo but maybe that's only available in Pivotal's network.

As far as M3 goes, do you think there would be any value in testing
against it?  I don't want to introduce new tests unless they are helpful.

Le 10/5/2016 à 5:31 PM, Anthony Baker a écrit :

Given that the official Pivotal maven repo [1] is locked behind a login
and a EULA I think this might not work so well.  The license compatibility
issues would need to be explored as well.

How would you feel about testing backwards compatibility against
1.0.0-incubating.M3?

Anthony

[1] http://commercial-repo.pivotal.io

On Oct 5, 2016, at 4:17 PM, Bruce Schuchardt <bschucha...@pivotal.io>
wrote:

We now have a backward-compatibility module but it's not well tested.
I'd
like to add tests to this module that run against GemFire jars
downloaded
from the Pivotal maven repository.  I've already implemented the
framework
and some smoke tests but want to know how people feel about the tests
downloading something proprietary to test against and whether failures
would be something the community cares about.

If we don't want this I'll keep it out of the repo until we have a
1.0.0
release to test against.


Reply via email to