On Wed, Mar 30, 2011 at 4:28 PM, sebb <seb...@gmail.com> wrote: > On 31 March 2011 00:17, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote: >> On Wed, Mar 30, 2011 at 7:04 PM, sebb <seb...@gmail.com> wrote: >> >>> But does the API have to change, or could these additional features be >>> supported by adding new methods and classes? >> >> Not necessarily. But my point is that codec is in a state where >> breaking the API will make work just easier. So why not take the >> opportunity? > > Because making work easier for a few developers has to be balanced > against making more work for lots of users. >
I'm confused. We support streaming for Base64 since codec-1.4 (and now Base32 since codec-1.5). You committed the Base64InputStream patch, Jochen! https://issues.apache.org/jira/browse/CODEC-69 Is there other streaming you would like to see in commons-codec? As for a 2.0 branch, even though the numbering (2.0) implies a break with reverse-compatibility, I still urge us to hesitate before breaking drop in reverse-compatibility. I agree with Sebb in this case. I think strong drop in reverse-compatibility is particularly welcome in cases like commons-codec: small, foundational, zero-dependency libraries, that are used everywhere! As for Java 5.0, sure go for it. Doesn't really benefit commons-codec that much, but doesn't hurt, either. As for JUnit 4.0, yes! Doesn't hurt any end users. -- yours, Julius Davies 250-592-2284 (Home) $ sudo apt-get install cowsay $ echo "Moo." | cowsay | cowsay -n | cowsay -n http://juliusdavies.ca/cowsay/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
