|
|
|
This page documents that roadmap and gives you an idea of what to expect from future versions and timeframes for release.
Our users keep inventing better ways and adding new requirements. The downside is that our todo list keeps growing. The upside is that there is plenty of work to go around. If you are interested in participating, send an email on the log4j-dev@ mailing list stating your interest. You'll be promptly enrolled. We're always looking for help! Don't be put off if in the "Volunteer" column already has a person listed. Programming is fun, especially if it is done in a team.
Expected timeframe: As needed
log4j 1.2.14 was released in September 2006. log4j 1.2 is continuing to be maintained in response to reported, but no active development is anticipated in the near future. Backporting the org.apache.log4j.rolling package from log4j 1.3 might be desirable since usage problems with the original org.apache.log4j.RollingFileAppender and org.apache.log4j.DailyRollingFileAppender are commonly reported.
Expected timeframe: indeterminate
Compatibility with earlier releases (as implied by a minor verion number change) was not enforced during the development process and much of the recent effort has been to restore compatibility. However, it does not seem likely that log4j 1.3 will ever been sufficiently compatible with log4j 1.2 to recommend it as a general replacement for log4j 1.2. Additional alpha releases are expected, however it is possible that the development focus may shift to log4j 2.0.
Expected timeframe: indeterminate
log4j 2.0 is still conceptual but would be designed for Java 5 and later, would use be designed for fine-grain concurrency to maximize performance on multi-processor systems, would minimize exposure of implementation details and adhere to current Java coding practices. The design of log4j 2.0 may attempt to support javax.util.logging by allowing, for example, a log4j 2.0 Appender to serve as a javax.util.logging.Handler. log4j 2.0 would likely be modularized, possibly using OSGi and would include a facade that emulates the log4j 1.3 API but would not be compatible with user written appenders and other components.