Seeing the discussion about [daemon] and not releasing made me think of another use for a test jar file.
What I would like to know when evaluating an RC for releasing a maintenance of a commons component (from x.y.n to x.y.n+1) is that there is 100% binary compatibility. As part of the build I would run (at least) the 1.0.2 unit tests against the 1.0.3 RC. If 100% pass all is well, if not, it is either a bug or a known acceptable failure fixing a bug and should be documented somehow, probably in a ticket. This would mean that a release 1.0.3 RC would include foo-test-1.0.2.jar. And maybe also foo-test-1.0.0.jar and foo-test-1.0.1.jar, hm... Thoughts? Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com From: Gary Gregory Sent: Tuesday, March 30, 2010 16:58 To: Commons Developers List Subject: [codec][lang] Provide a test jar I am starting with codec and lang since it what I am most interested in ATM... I would like to run commons.xxx unit tests as part of my build as a sanity check when I try out a new combo of JVM, OS, jars, etc. Right now, I would have to compile the unit tests as part of my build which is not great. So, what about providing a commons-codec-1.5-test.jar file like we provide a sources and javadoc file? Same for any commons project really... Thoughts? Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com
