With some reflection, another alternative is that when a project becomes dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a released project, they make sure that someone documents this in the STATUS.html.
Hen On Sun, 15 Dec 2002, Henri Yandell wrote: > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
