logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Next release of 2.0
Date Fri, 03 Jan 2014 17:21:56 GMT
The point of separating the API from the implementation was to try to address some of that.
 In Log4j 1 it isn’t clear at all where the public API stops.  Even though the API is separate
in Log4j 2 it is clear that we will want to be careful changing things like the Layout and
Appender interfaces since many users will implement their own custom components. 

Also, I have no problem adding to the API.

Ralph

On Jan 3, 2014, at 9:02 AM, Scott Deboy <scott.deboy@gmail.com> wrote:

> IMO, being unable to change the API in log4j1 due to compatibility
> concerns is what caused development of log4j to essentially stop
> (other than the occasional bug fix commit).
> 
> I'd hate for us to end up in the same place with log4j2.
> 
> Scott
> 
> On 1/3/14, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>> What are contemplating changing in log4j-api?
>> 
>> Ralph
>> 
>> 
>> On Jan 3, 2014, at 8:28 AM, Gary Gregory <garydgregory@gmail.com> wrote:
>> 
>>> On Fri, Jan 3, 2014 at 11:26 AM, Gary Gregory <garydgregory@gmail.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.
>>> 
>>> Gary
>>> 
>>> Gary
>>> 
>>> 
>>> On Fri, Jan 3, 2014 at 12:19 AM, Scott Deboy <scott.deboy@gmail.com>
>>> 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" <garydgregory@gmail.com> wrote:
>>> On Thu, Jan 2, 2014 at 10:15 PM, Remko Popma <remko.popma@gmail.com>
>>> 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.
>>> 
>>> Gary
>>> 
>>> 
>>> 
>>> On Fri, Jan 3, 2014 at 3:47 AM, Remko Popma <remko.popma@gmail.com>
>>> wrote:
>>> What tweaks do you have in mind? API changes?
>>> 
>>> 
>>> On Fri, Jan 3, 2014 at 12:45 AM, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>> On Thu, Jan 2, 2014 at 10:27 AM, Christian Grobmeier <grobmeier@gmail.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.
>>> 
>>> Gary
>>> 
>>> -------- Original message --------
>>> From: Ralph Goers <ralph.goers@dslextreme.com>
>>> Date:01/02/2014  02:46  (GMT-05:00)
>>> To: Log4J Developers List <log4j-dev@logging.apache.org>
>>> 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.
>>> 
>>> Ralph
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> 
>>> 
>>> ---
>>> http://www.grobmeier.de
>>> The Zen Programmer: http://bit.ly/12lC6DL
>>> @grobmeier
>>> GPG: 0xA5CC90DB
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> 
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message