Would love to see this. I'll go and put the historic Lang ones together if you let me know how you'd like it to look.
Hen On Mon, Apr 5, 2010 at 9:16 AM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
