commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [codec] promote from sandbox - RE: commons codec and Base64
Date Wed, 02 Apr 2003 22:38:42 GMT
In this particular case, why not release a "clean" commons-codec-1.0.jar
without the deprecated classes and a sandbox compatible
commons-codec-1.0-deprecated.jar (better name needed)? Isn't there a
precedent for this in other Jakarta projects?


-----Original Message-----
From: [] 
Sent: Wednesday, April 02, 2003 1:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [codec] promote from sandbox - RE: commons codec and Base64

> -----Original Message-----
> From: Stephen Colebourne [] 
> Promotion is probably a good idea, but it should be without 
> backwards compatability code IMO. You imply that there is a 
> codec 1.0 release, but this cannot be as sandbox components 
> may not have releases...

This is true, but not having a release doesn't mean that the project isn't
in use somewhere.  Check out the GUMP xref for commons-codec:  If you break codec, you
cause cascading failures in turbine-3 and scarab.  

Jon has voiced concern over backwards compatibility in the past, and in this
case I think leaving the old Base64 implementation in the next release is a
small matter.  The class is deprecated and it will be removed in the
subsequent release.

I don't think it is a good policy to require backwards compatibility for
sandbox components, but I think we have a special case here since codec has
been in use for a sustained period of time.  
I do agree that it shouldn't be the norm.

> Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

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