commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [codec][lang] Provide a test jar plus [daemon]
Date Mon, 05 Apr 2010 16:16:55 GMT
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: ggregory@seagullsoftware.com
email: ggregory@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: ggregory@seagullsoftware.com
email: ggregory@apache.org
www.seagullsoftware.com



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message