Re: [human-assisted gump] log4j back incompatible change

[Ceki Gülcü <ce...@qos.ch>]

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: [human-assisted gump] log4j back incompatible change

[Stefano Mazzocchi <st...@apache.org>]

Ceki Gülcü wrote:

> 
> 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. 

eheh, being at the bottom of the dependency chain is hard job :-)

> 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.

As I said, we (gumpers) don't care what solution is adopted, as long as 
one is :-)

> 
> 
>>  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.)

oh, there is no panic, just timely updates since gump is not (yet!) able 
to send email to the causer, but only to the ones effected.

Don't worry, we'll sort it out and we want to make gump a useful tool, 
not a silly noisy nagging bastard as it is today :-)

-- 
Stefano.