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

Tristan Tarrant ttarrant at redhat.com
Wed Nov 21 07:56:20 EST 2012


Before applying the chainsaw, we must first decide if we're going to 
have a 5.3.
Also 6.0 will have much more refactoring than just dropping 
org.infinispan.config.* so I think that should be handled first.

Tristan

On 11/21/2012 12:27 PM, Navin Surtani wrote:
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list