logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Next release
Date Tue, 15 Jul 2014 11:37:14 GMT
I don't really get tired of cutting releases.  I just want people to know we believe the code
is usable. ASIs the case with all software - or almost everything in life - it will never
be perfect.

Ralph

> On Jul 15, 2014, at 4:30 AM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> Easy for me to say 'do another RC' since I am not the RM but there is no harm in doing
a RC3, if anything it shows we are getting our ducks in a row before GA. My experience RM'ing
for Commons, HttpComponents and Xalan is that it is a pain in the you know what, so I won't
hold it against Ralph if he is tried of cutting releases ;-)
> 
> Gary
> 
> 
>> On Tue, Jul 15, 2014 at 7:17 AM, Bruce Brouwer <bruce.brouwer@gmail.com> wrote:
>> I am thinking I will commit my changes for 609 to the trunk tonight (unless i hear
otherwise) to get it included in 2.0. The impact to -api is pretty small so I will leave it
to you to decide if we need an rc3. My vote is we do. With this change I consider 609 to be
resolved.
>> 
>>> On Jul 14, 2014 5:42 PM, "Bruce Brouwer" <bruce.brouwer@gmail.com> wrote:
>>> In the latest stuff in my branch, the biggest change in api is StatusConsoleListener
moved to -core
>>> 
>>>> On Jul 14, 2014 1:23 PM, "Ralph Goers" <ralph.goers@dslextreme.com>
wrote:
>>>> StatusLogger is public in the sense that user written components will use
it.  But all we really expose to components there is the StatusLogger.getLogger() and the
Logger interface. The other public methods there are for JMX and the configuration to access
the status data. Nothing else under the status package is really public.  
>>>> 
>>>> I haven’t looked at Bruce’s changes yet but I can’t imagine how they
would result in API breakage.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>> 
>>>>> On Jul 14, 2014, at 10:04 AM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>> 
>>>>> If we break binary compatibility then we should change the package name.
This is to avoid well know jar hell issues. What we need to decide is which APIs are really
public. For example in Commons, all public APIs are part of the binary compatibility agreement
we've made. We now have lang3, pool2, dbcp2, for example. Looking ahead to not breaking binary
compatibility is why I think we need to be sure we agree now on what the public API is.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>> -------- Original message --------
>>>>> From: Remko Popma
>>>>> Date:07/14/2014 12:43 (GMT-05:00)
>>>>> To: Log4J Developers List
>>>>> Subject: Re: Next release
>>>>> 
>>>>> Bruce, I've done an initial review of the LOG4J2-609 branch and posted
some comments in the Jira.
>>>>> 
>>>>> Gary, I'm not in principle against changes to the API module in post-2.0
releases. Changes need to have enough merit to justify them, but if they do, then making these
changes before or after 2.0 doesn't matter that much to me. We've been in beta so long that
I'm sure we have quite a few users already, so to me we are live already. 
>>>>> 
>>>>> I do appreciate you want it to be as close to perfect as we can make
it. But I also agree with the others that releasing a GA version now won't prevent us from
making further improvements. 
>>>>> 
>>>>> By the way, when I told some people at work that we're close to the 2.0
release, their first impression was: "finally!" :-) 
>>>>> 
>>>>> 
>>>>>> On Mon, Jul 14, 2014 at 9:32 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>> I'll give the VOTE a review of course but I do not see the harm in
another RC since we will be setting the API in stone as soon as 2.0 is out. We also have only
one shot at a first impression. 
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>> -------- Original message --------
>>>>>> From: Ralph Goers
>>>>>> Date:07/14/2014 00:35 (GMT-05:00)
>>>>>> To: Log4J Developers List
>>>>>> Cc: Logging PMC
>>>>>> Subject: Re: Next release
>>>>>> 
>>>>>> I guess that means you won't be voting on the current release candidate?
Pretty much everyone else thinks it is time. If that is the case one of the other PMC members
will need to fail or the release vote will fail.
>>>>>> 
>>>>>> For what it is worth, I have no problem with a 2.0.1 or 2.1 in a
few weeks if desired.  I just think we have been stalling long enough.
>>>>>> 
>>>>>> And I hope we continue to keep fixing things at the same, or better,
pace.
>>>>>> 
>>>>>> Sent from my iPad
>>>>>> 
>>>>>>> On Jul 13, 2014, at 8:28 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>> 
>>>>>>> I'd be ok with another RC. My ideal scenario is that an RC is
released, some time goes by without new bug reports and then the next RC becomes a release.
As things are now, we've fixed plenty since rc2. But hey that's just me ;-)
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> 
>>>>>>> -------- Original message --------
>>>>>>> From: Bruce Brouwer
>>>>>>> Date:07/13/2014 22:35 (GMT-05:00)
>>>>>>> To: Log4J Developers List
>>>>>>> Subject: Re: Next release
>>>>>>> 
>>>>>>> Ok, the only test that didn't pass was the one testing for StatusLogger
writing to a file. I removed that test on the branch. If you review that and think it worthy
to go into the trunk, I'm pretty much on board with a 2.0 release (unless you think a short
lived rc3 is in order). 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sun, Jul 13, 2014 at 9:29 PM, Bruce Brouwer <bruce.brouwer@gmail.com>
wrote:
>>>>>>>> Ok, this is starting to be simpler, as I'm sure you would
all prefer. You can look at the branch LOG4J-609 again if you like. Here are the simplifications
that I have made.
>>>>>>>> 
>>>>>>>> 1) The listeners no longer report their level. They can decide
if they want to do something with a status message in their log method. 
>>>>>>>> 2) There is no longer the option to configure the StatusLogger
to write to a file. 
>>>>>>>> 3) I moved StatusConsoleListener out of log4j-api and into
log4j-core, where we can probably get away with making more drastic changes to it in the future
(so I can fix LOG4J-609)
>>>>>>>> 
>>>>>>>> I have to check on the tests and stuff, but in general, I'm
pretty happy with how small the impact is and in its ability to make a better solution for
LOG4J-609 possible in the future. 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker <boards@gmail.com>
wrote:
>>>>>>>>> This actually makes me wonder why you can configure the
status logger from a configuration file. Shouldn't this just be a system property or something?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 13 July 2014 18:57, Bruce Brouwer <bruce.brouwer@gmail.com>
wrote:
>>>>>>>>>> The listener can be removed, but nothing ever does.
Right now it can never know if it should be removed. And also, all that level checking is
cached in StatusLogger. If all you do is change the status level of the listener it has no
effect on the cached value in StatusLogger. It may end up having no effect.
>>>>>>>>>> 
>>>>>>>>>> This is some of the stuff I was trying to clean up
with my fix that I have been delinquent with.
>>>>>>>>>> 
>>>>>>>>>> I will try to simplify this on the branch and see
if it makes sense in the next hour or two.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Matt Sicker <boards@gmail.com>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> 
>>>>>>>>  
>>>>>>>> Bruce Brouwer
>>>>>>>> about.me/bruce.brouwer
>>>>>>>> 
>>>>>>>>  
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> 
>>>>>>>  
>>>>>>> Bruce Brouwer
>>>>>>> about.me/bruce.brouwer
>>>>>>> 
>>>>>>>  
> 
> 
> 
> -- 
> 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

Mime
View raw message