On Feb 28, 2005, at 10:00 AM, Ceki Gülcü wrote:
Curt's changes preserve absolute backward compatibility. Although quite reasonable, they add an additional layer of complexity. Preserving backward compatibility is a very important goal. At the same time, it can eventually lead to over-convoluted and unmaintainable code. In my opinion, it is more economical to ask authors of appenders to make small updates to their code in order to adapt to changes in log4j 1.3. Note that we are talking about small, easily performed adaptations. I believe that trying to preserve *perfect* backward compatibility is beyond our resources.
To summarize, I think that log4j committers have to choose between:
1) For the sake of improvement, we allow for small changes, even in core interfaces, at the cost of perfect backward compatibility.
2) No, perfect backward compatibility is an overriding principle, more important than other considerations.
Comments?
It shouldn't be a decision between an absolute fanatical perfect backwards compatibility and total chaos. However if I had to choose one at this time I would choose fanatical backwards compatibility. What I have been suggesting is that our general policy is to preserve backwards compatibility and that we discuss any exceptions either on discovery or prior to committing and require a vote when we knowingly break backwards compatibility.
A substantial proportion of code that uses log4j has to run in the context of another application or server and has no control over the version of log4j that is in use. I think it highly desirable that code that worked properly with 1.2 would continue to work properly. If there are compelling reasons and no reasonable alternative, we could consider adding additional requirements (like adding the detach method RepositorySelector) that can work under both 1.2 and 1.3. Only under the most extraordinary conditions, should we be forcing applications to choose between 1.2 and 1.3 or to add substantial complexity to be able to operate in both environments.
As I mentioned in a previous email, it appears that several significant projects have found themselves having to choose between 1.2 and 1.3. We should review the problems that they encountered and attempt to resolve them. They are serving as advance warning of the problems that will be encountered in much greater number as log4j 1.3 is evaluated by the wider body of log4j users. Breaking Hivemind may not be a big deal, but it may be a warning that we are breaking 10 or 100 times the number of non-ASF applications.
At this point I would consider the "core" interfaces like Appender and Layout nearly untouchable. The have proven that they are sufficient to represent the essential characteristics of their abstraction. Any additional enhancement or optimization could be exposed using additional interfaces or hidden within implementations.
In this particular instance, I would -1 both the additions to the Appender interface and the renaming of the activateOptions virtual method. The objectives of both (as have been revealed so far) could be accomplished without breaking backwards compatibility with very minimal additional complexity.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
