You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bruce Schuchardt <bs...@pivotal.io> on 2016/10/05 23:17:17 UTC
backward compatibility testing against GemFire 8.x WAN/clients
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.
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Bruce Schuchardt <bs...@pivotal.io>.
Thanks everyone. I'm going to keep the framework out of Geode, at least
for now. We can pick up the discussion again when we have a 1.0.0
Geode release to test against.
Le 10/6/2016 � 1:38 PM, Udo Kohlmeyer a �crit :
> 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
>> <bs...@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
>>>>>> <bs...@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.
>>>>>>>
>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
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 <bs...@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 <bs...@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.
>>>>>>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Jacob Barrett <jb...@pivotal.io>.
-1
Completely agree with Mark on this.
On Thu, Oct 6, 2016 at 9:31 AM Mark Bretl <as...@gmail.com> 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 <bs...@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 <bs...@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.
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Mark Bretl <as...@gmail.com>.
-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 <bs...@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 <bs...@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.
>>>>>
>>>>
>>>
>>
>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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
>>>> <bs...@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.
>>
>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Dick Cavender <dc...@pivotal.io>.
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
>>> <bs...@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.
>
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <bs...@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.
Re: backward compatibility testing against GemFire 8.x WAN/clients
Posted by Anthony Baker <ab...@pivotal.io>.
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 <bs...@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.