I disagree. A project which has not been released should not have to care about deprecation.
What your basically saying is that if someone adds a feature to CVS then it cannot later be removed but must be deprecated, even if not released. Whoever is the coder on Commons Email should be fixing it when they notice that the CVS HEAD they are dependent on has changed. The alternative you suggest is impossible beyond the simplest of systems. Hen On Sun, 15 Dec 2002, Jon Scott Stevens wrote: > http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/src/java/org/ > apache/commons/util/identifier/ > > You removed the GenerateUniqueId.java class and replaced it with some whole > subset of code which I'm sure is that much better, but the fact of the > matter is that there was other code which depended on GenerateUniqueId.java > being there and you didn't go and fix it (specifically the code in > commons-email). You need to learn how to do deprecation properly. > > So, either put GenerateUniqueId.java back or fix commons-email and next time > please learn how to use deprecation properly. > > -jon > > -- > StudioZ.tv /\ Bar/Nightclub/Entertainment > 314 11th Street @ Folsom /\ San Francisco > http://studioz.tv/ > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
