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?
Gary -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [mailto:[EMAIL PROTECTED] > > 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: http://cvs.apache.org/builds/gump/latest/xref.html. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
