[infinispan-dev] ISPN-2463: Hopefully one final question

[Navin Surtani]

Which would bring us to a point that Tristan made earlier. If for v 6.0, the whole org.infinispan.config.* package is going to be removed, should the code for this JIRA just be pushed on to a 6.0 branch and then I can just take my chainsaw to it directly? This way we finding the usages of the old API become a lot easier to find since there will be a lot more compilation errors. 


------------------------ 
Navin Surtani 


Software Engineer 
JBoss SET 
JBoss EAP 


Twitter: @navssurtani 

----- Original Message -----
From: "Sanne Grinovero" <sanne at infinispan.org>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Wednesday, November 21, 2012 6:42:57 PM
Subject: Re: [infinispan-dev] ISPN-2463: Hopefully one final question

Ideally one would need tests for both versions, but that sounds like a
lot of work to maintain something which is going to be removed soon.

In this case I think you should avoid rewriting many tests but take
advantage of the versioning system: since "old style" tests already
exists no point in recoding them.

Maybe it would be easier to already branch 5.2 vs. 6.0, so you can
apply testsuite changes only to 6.0 while packporting as much as
possible of code cleanup changes to 5.2: we'll have CI verify both on
each progress step so you inherently will keep tests around for both
5.2 and 6.0, verifying the same configuration.

The catch is that if you fail to backport some configuration change
from master to 5.2 we might not notice introducing a backwards
compatibility issue.

On 21 November 2012 10:26, Dan Berindei <dan.berindei at gmail.com> wrote:
> I think we should only keep the tests for the conversion between the new
> config and the legacy config (and the other way around), eventually add more
> of those.
>
>
> În data de 20.11.2012 09:57, "Tristan Tarrant" <ttarrant at redhat.com> a
> scris:
>
>> On 11/20/2012 03:47 AM, Navin Surtani wrote:
>> > Hey all,
>> >
>> > Nearly finished up with cleaning up the compile errors - should be able
>> > to run the test-suite by this afternoon in order to make sure that there
>> > aren't any failures. I was wondering, though, whether the tests in the
>> > package org.infinispan.config.* should still be making use of the deprecated
>> > configuration API? I understand that the point of this migration is to
>> > eliminate the use of org.infinispan.config.Configuration within the
>> > test-suite, but should just these specific tests still be testing the old
>> > method?
>> >
>> > My personal opinion is that we should still have tests making use of the
>> > old API as long as it does exist in the code-base. Speaking with Tristan on
>> > IRC last week, he mentioned that the org.infinispan.config.* package is
>> > likely to be totally removed in due course. I think that until that does
>> > actually happen, we ought to have tests for that code - deprecated or not.
>> >
>> > Thoughts?
>> Yes, we need to keep a sufficiently diverse set of "retro" tests so that
>> we don't risk breaking backwards compatibility.
>>
>> Tristan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev