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]
