commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [human-assisted gump] log4j back incompatible change
Date Fri, 29 Oct 2004 10:07:09 GMT

Hello Stefano,

We have been trying to shed the Category class for over 3 years. It
has been and still is an excruciatingly difficult and long process. As
long as source code does not directly refer to the Category class but
uses Logger instead, it should be compatible with both existing log4j
versions, in particular 1.2.x, and future log4j versions, and in particular
log4j 1.3.x.

Rest of my response below.

At 07:07 AM 10/29/2004, Stefano Mazzocchi wrote:
>Ceki,
>
>your action
>
>http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/Category.java?r1=1.88&r2=1.89&diff_format=h
>
>caused a compilation failure of the following projects:
>
>   - commons-logging
>   - velocity
>   - ant
>
>and, as a result, caused a drop in the gump's success from 83% to 53%, for 
>more info see:
>
>  http://brutus.apache.org/gump/public/project_todos.html
>
>Now, since this is a back incompatible change, we (the gumpmeisters) would 
>like to know:
>
>  1) if you might be willing to revert the change if you did not intend to 
> cause such effect
>
>  2) if not, if you are willing to move the previous version of the tree 
> into a branch so that we can migrate the dependencies to that

Changes that do not allow existing client code to be compatible with
both 1.2.x and 1.3.x will be reverted. However, existing client code
should also make an effort not to use or refer to the Category
class. I believe that as long as client code does not refer to the
Category class but uses Logger instead, then both backward and forward
compatibility should be achievable.


>  3) if not, if you are willing to work with the offended dependees to 
> restore their success status.

That goes without saying. Allow me to look more closely at the
specific failures so that I can compile a precise recipe for restoring
success.

I think it is important that we do not panic and address each error
individually. (This is an appeal to myself as much as the rest of the
bunch.)

>  4) if not, if you have any alternative suggestion on how to move forward.
>
>please understand that we have no preference in which road the log4j 
>project decides to go, we are only interested in giving a chance to those 
>322 projects that were affected by this to keep having build information.
>
>Thank you very much in advance for your cooperation.
>
>--
>Stefano, doing by hand what gump should be able to do in the future.

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      http://www.qos.ch/shop/products/eclm/  



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message