> -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED] > Sent: 20 May 2005 18:17 > To: 'Log4J Developers List' > Subject: RE: [VOTE][RESULT] Release Overview Proposal > > If there are problems or concerns about how it will affect the 1.2.X base, > then yes, anyone can call a vote. Then we can decide to change what is > 1.3 > today to 1.4 and reuse the 1.3 release for this (1.2 + TRACE). :-) > > I was also thinking a different 1.3 release might be a good opportunity to > deprecate more stuff currently deprecated on the cvs head, just to give > folks more of a heads up.
+1 That just about summed up what I have been trying to say. Whilst I accept that by extending log4j classes I take on the responsibility to have to change them when log4j changes, a deprecation release would be most useful to give me time to rethink my current implementation. There are lots of improvements in the HEAD (1.3) codebase that I would love to take advantage of but I have to wait until a final release before I can adopt for production. A 1.3 release based on 1.2 + TRACE + deprecations + bugfixes would be a good stage to prepare my application for whatever label the current CVS HEAD becomes. I would rather encourage debate rather than call for a vote on this just now. Regards Andy > > -Mark > > > -----Original Message----- > > From: Curt Arnold [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 18, 2005 2:46 PM > > To: Log4J Developers List > > Subject: Re: [VOTE][RESULT] Release Overview Proposal > > > > > > On May 18, 2005, at 2:54 PM, Ceki Gülcü wrote: > > > I'd lean against adding the TRACE level to the 1.2 branch. Scott > > > and Jake may feel the same way. In my opinion, the TRACE level > > > promotes bad habits, especially in light of the confusion between > > > TRACE and DEBUG. There is also the question of backward > > > compatibility over the wire. If TRACE was introduced in 1.2.11 it > > > would be incompatible with versions 1.2.9 and earlier. > > > > I don't think adding trace would necessarily break serialization > > compatibility, but it would be something to check. If serialization > > incompatibility was unavoidable, then I would assume that we would > > vote to release 1.2.12 without the TRACE level but with the other bug > > fixes. I can backport my serialization compatibility tests from the > > 1.3 branch as soon as 1.2.11 is released, so changes in serialization > > will be detected quickly. > > > > > > --------------------------------------------------------------------- > > 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]
