I appreciate your comments.
I think one needs to approach these questions with pragmatism. Maintaining absolute (as in total) backward compatibility in presence of evolution is an incredibly costly proposal. It is beyond reach for everyone except perhaps the largest software companies. Even in the case of Microsoft, the cost of maintaining backward compatibility is so high that even they eventually give up and start over from a different point. The recent backward compatibility changes in log4j correct 0.01% of incompatibility problems whereas the binary compatibility problem accounting for 99.99% of cases has not been corrected. In all fairness, it's a tough nut to crack. As for JCL, the changes are not about the interface but its implementation. I am not aware of anyone using the MarkerLogger interface. Are you using it? As for your comments about the significance of release candidate, you are right. However, I rather perform the change now instead of later, say after the release of 1.0final. At 04:22 PM 1/26/2006, you wrote:
My last mail did not correspond to the actual changes in svn. Some of my questions/points found answers through that. > I intend to merge methods in MarkingLogger back into Logger with the > understanding that the bindings for logging systems without marker > support would simply ignore the Marker data (as was the vase prior to > SLF4J 1.0beta8). > Comments? What is very misleading for users: On http://www.slf4j.org/download.html one can download a *ReleaseCandidate* five. Most other open source projects have a very conservative version numbering and (different to many commercial software) show with the number what the state is really. (Think of JDOM which was a very long time 0.x before release and "final"). The log4j team and JCL team currently heavily works on backwards compatibility (I do not write "reach") - users excpect that from a core infrastructure API. Maybe your changes are compatible for users of "Logger", but what about users of "MarkingLogger"? A release candidate can have bugfixes and documentation add-ons but interfaces should not change. Please consider to change the version number back to 0.x and clearly state on the homepage something like "experimental", "alpha" or "subject to change" so everyone knows where the project stands. Regards Boris
-- Ceki Gülcü _______________________________________________ dev mailing list dev@slf4j.org http://slf4j.org/mailman/listinfo/dev
