Regarding adding a trace level to 1.2 if this is done it would be good to have a way to externally detect whether the version supports a trace level. Commons Logging currently detects pre-1.3 log4j version and acts accordingly by checking Priority.class.isAssignableFrom(Level.class) though where trace is concerned it doesn't but that is another story. If a trace level where added to 1.2 the test in JCL for pre-1.3 version isn't going to pick it up. If there were some other way in 1.2 to know the version then JCL can be modified to correctly map their trace to log4 trace rather than log4j debug. The result would be a user of both log4j and JCL who is up-to-date with current (minor) version would be able to take advanage of trace in log4j.

As for adding a trace level before the major release, please do! I look forward to giving an early retirement to trace4j http://home.comcast.net/~pdegregorio/ a clone of log4 1.2.9 with trace enabled.

Peter

----- Original Message ----- From: "Paul Smith" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[email protected]>
Sent: Thursday, May 12, 2005 3:47 AM
Subject: Re: [VOTE] Release Overview



Mark, I appreciate your energy you have at the moment, it's inspiring.

On 12/05/2005, at 3:05 PM, Mark Womack wrote:



2) Abandon the 1.3 version number, the main branch becomes version 1.5 below.

If we do this, we should probably post some rationale to the rest of the community, everyone's been following 1.3, so we should be open about how this all came to be. Lets not "Do a Sun" and change labels for the hell of it without a clear message to the community.



3) Release a 1.4 version with the TRACE change and other fixes that will make life happier for the user base (action item: determine the other changes). No major structural changes. Just most "important" bugfixes. The base of the 1.4 code would start from the v1_2branch. Timeframe is within a month of the 1.2.11 release.


This action has the risk that 1.4 blows out to be a bigger release than necessary. It will also mean that quite a bit of back-porting effort will be needed. This stuff is already in HEAD, and will require time and testing to make sure it's perfect ported to the older branch..

This is the classic time investment problem. Do we keep plowing ahead to 1.3 completion, setting only very small goals to be left to do for 1.3? We have the advantage at the moment that people are trying out 1.3 as it stands now, and going through the change management, I'd hate for them to through that effort away. (as a side note: we'll need good documentation on how to convert a project from 1.2.x to 1.3/1.5)

I think the 1.4 release as you suggest is going to be a big distraction. The _last_ thing we want is a poor release, and so I see poor-old-1.3-now-1.5 not nearing completion till next year because we'll spend so much time on 1.4... :( I'm not saying we shouldn't do this, just expressing my feelings.

4) Release a 1.5 version based on the current main branch. This would be what we are calling v1.3 today. Timeframe: release of first final version by 10/2005.

This is sad, because so many people have problems with the DailyRollingFileAppender that 1.3 could solve, but I know trying to fix that in 1.4 is asking for trouble.


I am +1 on the above, and I am committing to make it happen. I am willing to be the release manager for the proposed versions. We will all need to focus and do what we need to complete these releases, especially v1.5.

I'm willing to put up and help with whatever if someone can help me by saying "I think you can do this, can you have it done by such-n- such". I know that probably makes me sound like a baby, but it's more likely I'll commit and actually do it right now! :) Life is really full on for me at the moment.

I hope I don't come across as a Negative Nelly. I'm glad that we're actively having this discussion, because I feel we have drifted along for a while (and I've just drifted along without doing anything for a while).

Please, those non log4j developers, speak up with your say about what you want.

cheers,

Paul Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to