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" <[email protected]> To: "infinispan -Dev List" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
