On 02/12/2009, Julius Davies <juliusdav...@gmail.com> wrote: > Hi, > > Any opinions at all out there regarding this? > > https://issues.apache.org/jira/browse/CODEC-89 > > > Mat Booth, the Fedora commons-codec maintainer, left a message today > on CODEC-89: > --- > [...] > It definitely feels like a regression to me – I'm tempted to apply > this patch to the commons-codec distributed by Fedora Linux (I am the > maintainer there). > --- > > > Gary Gregory posted this on CODEC-89 a week ago: > --- > If you want, you can post to the dev list to ask for the community's > feedback. It would be good to see what other people think. > --- > > And that's why I wrote the original email. So, like I said up above: > > Any opinions at all out there regarding this? > >
Whatever happens, someone is going to be unhappy. But on the whole, I agree that if the behaviour was mistakenly changed between 1.3 and 1.4 then it should be reverted, and release 1.4 deprecated (if such is possible). > > > yours, > > > Julius > > > > On Mon, Nov 23, 2009 at 12:24 PM, Julius Davies <juliusdav...@gmail.com> > wrote: > > Hi, Commons Developers, > > > > > > There's a minor regression in Codec-1.4 that causes two extra white > > space characters to appear at the very end of the Base64 output when > > using the instance encode() method instead of the static one: > > > > https://issues.apache.org/jira/browse/CODEC-89 > > > > This seems to be causing some interop problems for clients. For > > example, one person on the commons-user mailing list appeared to be > > comparing output of Codec-1.4 against values stored in a database > > using Codec-1.3 - so obviously they are having problems! They can > > workaround using trim() or switching to the static method, but they > > don't expect to have this problem. > > > > I suspect this problem is also behind the issues these people > > experienced, but that's all I could find after about 15 minutes > > playing with the google. > > > > > http://alphawit.com/blog/2009/oct/12/amazon-vs-apache-my-base64-better-your-base64/ > > > > http://code.google.com/p/oauth-signpost/issues/detail?id=18 > > > > > > > > Should we release a 1.4.1 and fix the API to bring it back inline with > > Commons-Codec-1.3? (If yes, then the sooner the better I think!) Or > > should we leave the API as it is? > > > > Sorry I didn't catch this earlier. My patches caused this problem. I > > was careful to make sure the static method had stayed the same in > > Codec-1.3 and Codec-1.4, but I just never thought people would > > actually write things like this: > > > > new Base64().encode() !!! > > > > Just didn't enter my mind to test that to compare output of 1.3 vs > > 1.4. Very sorry. :-( > > > > > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > 250-893-4579 (Mobile) > http://juliusdavies.ca/logging.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
