On Fri, Jan 3, 2014 at 11:26 AM, Gary Gregory <email@example.com> wrote:I'm not sure what policy WRT binary and source compatibility we have in log4j 1 and 2. Over in Commons, if you break BC, in general, that means a package name change and a Maven name change, for example from o.a.commons.lang to lang3. This is using the Clirr report to check for errors. There are exceptions of course, usually if a public API changes but it is considered part of the implementation and not what a call site should use.I forgot to mention, in Log4j, we have a more stringent requirement since there are users of log4j and implementors of appenders. So some of the log4j guts are necessarily public to allow Appender implementations to be written.GaryGaryOn Fri, Jan 3, 2014 at 12:19 AM, Scott Deboy <firstname.lastname@example.org> wrote:
I think it makes sense to go through the existing bugs and find ones we feel are critical and squash them before a final 2.0.
Gary's right in the sense that adoption as a non beta means we will feel resistance to significant changes.
Maybe we should make it clear that Api changes may appear in 2.1 but not 2.0.x?On Jan 2, 2014 7:23 PM, "Gary Gregory" <email@example.com> wrote:On Thu, Jan 2, 2014 at 10:15 PM, Remko Popma <firstname.lastname@example.org> wrote:Frankly, Gary, I don't understand the hesitation.We started talking about a 2.0 GA release six months ago. Surely that should have been enough time to familiarize yourself with the APIs and raise any concerns.I understand that the 2.0 release is a big step but I also agree with Christian that if unforeseen issues come up we can address them in upcoming releases. (And if we find we've made a terrible mistake and need an API change, then so be it...)How about everyone marks outstanding Jira tickets that they really want to address before the 2.0 release (with the issue target version), and release the 2.0 GA when these are all fixed?Hey, it's a volunteer community process, and we all have our opinions ;) I just stated mine is all.Feel free to call a vote when you see fit. It's all good.GaryOn Fri, Jan 3, 2014 at 3:47 AM, Remko Popma <email@example.com> wrote:What tweaks do you have in mind? API changes?On Fri, Jan 3, 2014 at 12:45 AM, Gary Gregory <firstname.lastname@example.org> wrote:On Thu, Jan 2, 2014 at 10:27 AM, Christian Grobmeier <email@example.com> wrote:Why the caution?
We can have a 3.0, a 2.1 and son on.
Nobody expects we should stick forever with a version.
On the other hand, we were releasing in beta for ages now.
What are the reasons you don't want a 2.0 stable?You've got it backwards ;)I do want a stable 2.0. I, personally, am not 100% familiar with 100% of the API and I am not sure that the API is stable. There are a LOT of _public_ APIs in Log4J. Once 2.0 is out, these are set in stone.
There are also a couple of tweaks I'd like to do. People are using log4j now in beta form. Another beta/rc will not hurt. But once 2.0 is out, we are set.Gary
On 2 Jan 2014, at 14:04, Gary Gregory wrote:Make it RC or another beta IMO. Once 2.0 is out you cannot unhinged that bell.
-------- Original message --------From: Ralph Goers <firstname.lastname@example.org>
Date:01/02/2014 02:46 (GMT-05:00)To: Log4J Developers List <email@example.com>
Subject: Next release of 2.0
I am trying to find a bit more time to work on Log4j again. I see quite a few issues that I would like to address and think I will need about 2 weeks to complete them so I am tentatively targeting the middle of the month for the next release. The question in my mind is whether the next release should be 2.0-RC1 or just 2.0.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com