commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <juliusdav...@gmail.com>
Subject Re: [codec] Moving on to codec 2.0
Date Thu, 31 Mar 2011 19:23:46 GMT
On Wed, Mar 30, 2011 at 4:28 PM, sebb <sebbaz@gmail.com> wrote:
> On 31 March 2011 00:17, Jochen Wiedmann <jochen.wiedmann@gmail.com> wrote:
>> On Wed, Mar 30, 2011 at 7:04 PM, sebb <sebbaz@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message