True, but neither has HttpClient 2.1:) We will most likely have to put some effort into getting a final codec release that contains this code.
I agree, adding a jar could be considered an API break, but it was part of our plan for 2.1. The only real API changes that this requires is removing the already deprecated Base64 code. The EncodingUtil class will not be changed.
Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now.
Chill out, dude. Personally, I was not "insisting" on "complete (maximum) API compatibility", but was just offended/scared by your tone. I didn't expect to hear "we guarantee 100% backwards compatibility", just a "we'll try to preserve backwards compatibility as much as possible".
I have read the 2.1 release plan when it was posted, and if I (as a user) would not have been in agreement, I'd have voiced my concerns. I also think that migrating to Commons-Codec is a good idea, and it should be a very managable change for all API clients (for example, there's no problem adding Commons-Codec to the classpath of HttpClient 2.0.x).
Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm.
You could also work on choosing your words more carefully sometimes, put a little smiley behind sarcastic statements, and fix your caps lock ;-)
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
