I believe we need a focused goal as to what we need to achieve for 1.3. This means coming up with ThePlan(tm) (again) as a group, delegate the work, and check in regularly as to how we're tracking?
cheers,
Paul
On 11/05/2005, at 6:02 AM, Mark Womack wrote:
OK, this is my opinion here. I want to hear what the other committers have
to say on this topic.
I want to get v1.3 out. I want us to finish what we have started,
consolidate it, test it, and release it. I want it to be released before
the end of the year, preferably more in the Sep/Oct timeframe. We've been
doing some great stuff, we've been doing it for a while, we need to get it
into the hands of our users. Ceki and I presented the bulk of the features
for v1.3 back in Nov 2003 at ApacheCon. It will be almost 2 years!
I don't want anything to get in the way of this. I don't want to start any
new features, I don't want to open any new issues or topics. That is not to
say that these issues are not important, I agree they are. I just think
that opening them up is going to delay us from getting the other really cool
1.3 stuff out.
Also, to me, a 2.0 designation could/should be used to indicate some
fundamental changes/shift in the api/architecture. If we are going to break
some pre-existing longstanding contracts, the 2.0 version is the time to do
it. Let's go wild. So, again, I think doing it will require more thought
and discussion than I want to take place to get a release out soon.
Ok, those are my thoughts.
-Mark
-----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 10, 2005 9:56 AM To: Log4J Developers List Subject: Relabeling log4j 1.3 as 2.0
There have been suggestions that it may be beneficial to relabel the current log4j 1.3 branch as log4j 2.0 and have an interim minor release from the 1.2.x branch designated 1.2.11 or 1.4.0 (will be raised in a separate thread).
The current 1.3 branch is a substantial enough change from the 1.2 code base that there have been (and continue) many inadvertent or unexpected compatibility issues with 1.2, however the minor release designation has prevented desirable code changes that may cause some breakage. For example, many classes that should not be extended (Logger and LoggingEvent) were not declared as final. It is possible that some users have been able to successfully extend those classes in limited ways, so designating them as final is not an appropriate change for minor release.
Some potential things I could see that could be tolerated in a 2.0 release that wouldn't fit in a 1.3 (please let me know any I have left out)
Designating classes not designed for extension as final. Lowering visibility of members and methods, particularly making protected member variables private and changing package visible member methods. Dropping JDK 1.1 collection types Finer grain synchronization with potentially some changes in locking semantics. Using JDK 1.5 typed collections on JDK 1.5+ while still supporting JDK 1.2 collections.
Hopefully these could be accomplished without compromising client
code, but may break some amount of custom appenders, layouts and such.
We are all anxious to have something to show for the long development
time of the 1.3 branch, but as much as we've changed, it would be a
missed opportunity not to break things that should be broken. I
would however prefer this not be an excuse for breaking things that
should not have been broken and pushing back the release targets.
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
