To fix GEODE-7168 I have modified the backward-compatibility framework
to preserve periods in version names. Prior to the change versions were
in the form "100", "110", "120", etc. Now they are "1.0.0-incubating",
"1.1.0", "1.2.0", etc.
When requesting a VM that's running a particular versio
It would be nice to know if a test is going to use an old version. Then
we could boot the appropriate locator for it. I don't have anything
like that implemented yet - there is still only one locator prestarted
by the DUnit launcher.
Le 1/19/2017 à 1:30 PM, Dan Smith a écrit :
Does this mean
7;ve extended the distributedTest framework to let us do
> backward-compatibility testing. Once it is reviewed and committed people
> will be needed to modify existing tests to run against multiple versions of
> Geode.
>
> Here is the RB review: https://reviews.apache.org/r/55688/
pression that 1.1 was going to be compatible with 1.0. Is
>>> that
>>> not the case? Why do the tests need to have peers with different versions
>>> if we are not supporting that? Is there a way we can do these tests
>>> without
>>> having the product
<
bschucha...@pivotal.io>
wrote:
I've extended the distributedTest framework to let us do
backward-compatibility testing. Once it is reviewed and committed
people
will be needed to modify existing tests to run against multiple
versions of
Geode.
Here is the RB review: https://reviews.apach
need to have peers with different versions
>>> if we are not supporting that? Is there a way we can do these tests
>>> without
>>> having the product code behave differently when it is being tested than
>>> when it is being used normally?
>>>
>>> -Dan
>
do these tests
without
having the product code behave differently when it is being tested than
when it is being used normally?
-Dan
On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt
wrote:
I've extended the distributedTest framework to let us do
backward-compatibility testing. Once
e differently when it is being tested than
when it is being used normally?
-Dan
On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt
wrote:
I've extended the distributedTest framework to let us do
backward-compatibility testing. Once it is reviewed and committed people
will be needed to modify
normally?
-Dan
On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt
wrote:
> I've extended the distributedTest framework to let us do
> backward-compatibility testing. Once it is reviewed and committed people
> will be needed to modify existing tests to run against multiple versi
> On Jan 18, 2017, at 3:11 PM, Bruce Schuchardt wrote:
>
> I've extended the distributedTest framework to let us do
> backward-compatibility testing. Once it is reviewed and committed people
> will be needed to modify existing tests to run against multiple versions of
&
> +1 Nice work Bruce
>>
>>
>>
>>> On 1/18/17 15:11, Bruce Schuchardt wrote:
>>>
>>> I've extended the distributedTest framework to let us do
>>> backward-compatibility testing. Once it is reviewed and committed people
>>>
JVM
>> that's set up to use the requested version. You can then use the normal
>> method/lambda invocation methods to run code in that JVM.
>>
>> Currently version "100" (1.0.0-incubating) is available for
>> backward-compatibility testing. Versions to be tested are configured in
>> geode-old-versions/build.gradle as source-sets. Adding a new version is
>> trivial.
>>
>
>
+1 Nice work Bruce
On 1/18/17 15:11, Bruce Schuchardt wrote:
I've extended the distributedTest framework to let us do
backward-compatibility testing. Once it is reviewed and committed
people will be needed to modify existing tests to run against multiple
versions of Geode.
Here is t
I've extended the distributedTest framework to let us do
backward-compatibility testing. Once it is reviewed and committed
people will be needed to modify existing tests to run against multiple
versions of Geode.
Here is the RB review: https://reviews.apache.org/r/55688/
The diff in
14 matches
Mail list logo
