Commons Logging 1.1.0 ReleasePlan


This is an important release: JCL is very widely used in production but a combination of new specifications and widespread failures from vendors to adhere to the Java 2 classloading model have resulted in majors problems for the JCL 1.0.x series of releases.

Thanks to constructive criticism from Ceki Gülcü and new energy from new developers, changes have been made to the discovery model used by JCL. The current codebase is now more specification agnostic: it no longer insists on compliance with the classloader models introduced in Java 1.2 and in the servlet specification. It is believed by the team that the current codebase should solve those problems which can be solved given the design approach taken by JCL.


Preparations for Alpha 1

Release Process

Most commons components use a release that uses multiple release candidates. Once the release is up to the technical standards required for Jakarta Commons releases, it is approved and released.

JCL 1.1.0 is an important release. Not only is JCL very widely used but the limitations of the 1.0.x series of releases has been widely reported. It is important that the 1.1 release not only resolves these problems but also does not introduce any new ones. It is also tricky to unit test situations involving exotic classloaders, so help from users of JCL is needed to verify that this new release works in unusual circumstances.

I'd therefore like to propose the following additions to the process. Release candidates will be produced as normal until one satisfies the standards required for commons releases. At that stage, though, the release will be dubbed commons-logging-1.1-alpha1. An announcement will be made requesting that users, developers and committers test this release. If there are no problems then a subsequent VOTE will be held to promote this release.

The release will be recut each time but no code modifications will be made without resetting the process.

Pre-Release Tasks

Anyone who wants to volunteer for a task, just add something

Documentation Review

Bug Review

Bug Fixes

Design decisions

Work To Resolve Design Issues

sub-components don't work very well. in particular, i think too many users are going to get too confused by yet another jar. WeakHashMap will go into the base distribution, other classes will be moved into contrib. perhaps another component (logging-extras) would be good or perhaps moving them off shore.

demonstration will be moved into contrib

add an ant task that creates a distribution with minimal dependencies. create guide to help people understand the distribution with section on dependencies.

log4j 1.3 is still not released. the new JCL release cannot depend on unreleased code. the 1.3 implementation will be moved into contrib. Log4JLogger and Log4J12Logger will be shipped with notes that direct use of log4jlogger is deprecated and will be replaced by a logical logger when log4j 1.3 ships.

this will be shipped. The critical issue was that projects which repackage JCL (eg by compiling with gcj) may not have an implementation of javax.servlet to compile against. However the commons-logging-api.jar project now contains all the stand-alone loggers, and this should be enough for most circumstances. Because such "repackagers" can create and distribute commons-logging-api.jar, it has been decided that it is acceptable for the commons-logging.jar to have a compile dependency on javax.servlet.

Test Compatibility

Verify that TRACE support works for Log4J 1.2.12+. DONE

Release Notes

Release Plan


Release Notes

Approval Process

Release Candidate

Post Release

Process Bugs Marked Later


Up to Logging

Logging/1.1.0ReleasePlan (last edited 2009-09-20 23:48:23 by localhost)