Re: Performance page for next release.

> it's okay to let some time elapse if we're busy with other things. >> >> Anyway, if just the JMH tests are ok, I'll try to do this in the next month. >> >> Remko >> >> Sent from my iPhone >> >> > On Mar 3, 2017, at 17:24, Ralph Goers &l

Re: Performance page for next release.

ts are ok, I'll try to do this in the next > month. > > Remko > > Sent from my iPhone > > > On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > Remko, > > > > Would it be possible for you to update the performance

Re: Performance page for next release.

gt;> Sent from my iPhone >> >>> On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>> Remko, >>> >>> Would it be possible for you to update the performance page for the next >>> release? I am uncomfortable

Re: Performance page for next release.

ll try to do this in the next month. > > Remko > > Sent from my iPhone > >> On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> Remko, >> >> Would it be possible for you to update the performance page for the next >

Re: Performance page for next release.

are ok, I'll try to do this in the next month. Remko Sent from my iPhone > On Mar 3, 2017, at 17:24, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Remko, > > Would it be possible for you to update the performance page for the next > release? I am uncomfortable

Performance page for next release.

Remko, Would it be possible for you to update the performance page for the next release? I am uncomfortable with some of the results because I know they have changed since 2.6. Ralph - To unsubscribe, e-mail: log4j-dev

Re: Next release

Thank you for RM'ing again. I do not have any blockers for a release. Gary On Dec 16, 2016 7:22 AM, "Apache" <ralph.go...@dslextreme.com> wrote: I should have some time between Dec 24 through Jan 2 to perform the next release. If there are any critical bugs that need to be addr

Re: Next release

; If we cannot do 1691 (new scala repo), I would like to do 1661 (Scala > 2.12) and 1690 (Scala wrapper for context map) in the current repo. > > On Fri, Dec 16, 2016 at 4:21 PM, Apache <ralph.go...@dslextreme.com> > wrote: > >> I should have some time between Dec 24 th

Re: Next release

rapper for context map) in the current repo. On Fri, Dec 16, 2016 at 4:21 PM, Apache <ralph.go...@dslextreme.com> wrote: > I should have some time between Dec 24 through Jan 2 to perform the next > release. If there are any critical bugs that need to be addressed please > try to have them co

Next release

I should have some time between Dec 24 through Jan 2 to perform the next release. If there are any critical bugs that need to be addressed please try to have them completed shortly after Christmas. Ralph - To unsubscribe, e

Re: Version number of next release

gmail.com> > wrote: > >> On Thu, Nov 3, 2016 at 1:08 AM, Remko Popma <remko.po...@gmail.com> >> wrote: >> >>> Considering that LOG4J2-1660 >>> <https://issues.apache.org/jira/browse/LOG4J2-1660> is an API change, >>> the next release shou

Re: Version number of next release

Yes, seems reasonable. On Thu, Nov 3, 2016 at 9:29 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Thu, Nov 3, 2016 at 1:08 AM, Remko Popma <remko.po...@gmail.com> wrote: > >> Considering that LOG4J2-1660 >> <https://issues.apache.org/jira/browse/LOG4J2-16

Re: Version number of next release

On Thu, Nov 3, 2016 at 1:08 AM, Remko Popma <remko.po...@gmail.com> wrote: > Considering that LOG4J2-1660 > <https://issues.apache.org/jira/browse/LOG4J2-1660> is an API change, the > next release should probably have version number 2.8 instead of 2.7.1. > Thoughts?

Version number of next release

Considering that LOG4J2-1660 <https://issues.apache.org/jira/browse/LOG4J2-1660> is an API change, the next release should probably have version number 2.8 instead of 2.7.1. Thoughts?

Re: [Discuss] features and issues for the next release

To ease migration from Log4j 1, we could provide a AppenderSkeletonAppennder. This would be a Log4j 2 Appender that delegates to a Log4j 1 Appender. This might make it easier to for projects like Hadoop to migrate since they have custom Log4j 1 appenders. You could configure such an appender with

[Discuss] features and issues for the next release

Leon, Thanks for the feedback! Are there any other issues you are aware of that need to be addressed or any features you need? If so, are any that you would like to contribute to? Ralph > On Sep 27, 2016, at 9:39 AM, Leon Finker wrote: > > +1 > Tested with various

Re: Next release 2.4 vs. 2.3.1

I wouldn’t bump it just for those things. However, I think we have to do it due to the move to Java 7. If we ever need to do a patch release for Java 6 we need to reserve 2.3.x for that. Ralph On May 18, 2015, at 10:53 PM, Gary Gregory garydgreg...@gmail.com wrote: Considering the addition

Re: Next release 2.4 vs. 2.3.1

OK. so I bumped the version from 2.3.1 to 2.4 for the next release. We have a new platform requirement: Java 7 (instead of Java 6), two minor new features, and a few small bug fixes so far. Gary On Mon, May 18, 2015 at 11:09 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I wouldn’t bump

Re: Next release 2.4 vs. 2.3.1

I think we should modify the downloads page so that it is clear to download version 2.3 for Java 6 and the latest release for Java 7. Ralph On May 19, 2015, at 8:34 AM, Gary Gregory garydgreg...@gmail.com wrote: OK. so I bumped the version from 2.3.1 to 2.4 for the next release. We have

Re: Next release should be 2.2

, at 23:14, Gary Gregory garydgreg...@gmail.com wrote: I meant 2.3, not 2.2, duh. Gary -- Forwarded message -- From: Gary Gregory garydgreg...@gmail.com Date: Mon, Mar 9, 2015 at 2:54 PM Subject: Re: Next release should be 2.2 To: Log4J Developers List log4j-dev

Re: Next release should be 2.2

garydgreg...@gmail.com Date: Mon, Mar 9, 2015 at 2:54 PM Subject: Re: Next release should be 2.2 To: Log4J Developers List log4j-dev@logging.apache.org Unless I hear owls, I'll remove version 2.2.1 from JIRA which will allow all issues marked as 2.2.1 to be changed to 2.2. Gary On Mon

Re: Next release should be 2.2

, duh. Gary -- Forwarded message -- From: Gary Gregory garydgreg...@gmail.com Date: Mon, Mar 9, 2015 at 2:54 PM Subject: Re: Next release should be 2.2 To: Log4J Developers List log4j-dev@logging.apache.org Unless I hear owls, I'll remove version 2.2.1 from JIRA which

Re: Next release should be 2.2

: Next release should be 2.2 To: Log4J Developers List log4j-dev@logging.apache.org Unless I hear owls, I'll remove version 2.2.1 from JIRA which will allow all issues marked as 2.2.1 to be changed to 2.2. Gary On Mon, Mar 9, 2015 at 2:52 PM, Gary Gregory garydgreg...@gmail.com wrote: Hi

Next release should be 2.2

Hi All: With today's patch for: LOG4J2-926 Truncate from the end of text format modifier I've bumped the next release version 2.2 instead of 2.2.1 because this is a new minor feature. Previously, all patches were bug fixes. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java

Re: Next release should be 2.2

I've bumped the next release version 2.2 instead of 2.2.1 because this is a new minor feature. Previously, all patches were bug fixes. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit

Fwd: Next release should be 2.2

I meant 2.3, not 2.2, duh. Gary -- Forwarded message -- From: Gary Gregory garydgreg...@gmail.com Date: Mon, Mar 9, 2015 at 2:54 PM Subject: Re: Next release should be 2.2 To: Log4J Developers List log4j-dev@logging.apache.org Unless I hear owls, I'll remove version 2.2.1 from

Re: Next release

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

Re: Next release

. 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

Re: Next release

, 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

Re: Next release

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

Re: Next release

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

Re: Next release

/14/2014 00:35 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivCc: Logging PMC priv...@logging.apache.org /divdivSubject: Re: Next release /divdiv /divI guess that means you won't be voting on the current release candidate? Pretty much everyone else thinks

Re: Next release

: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next release /divdiv /divBruce, 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

Re: Next release

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

Re: Next release

: 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

Re: Next release

On Sunday, July 13, 2014, Bruno Mahé bm...@tango.me wrote: Hi, We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed. We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out. The

Re: Next release

On Sunday, July 13, 2014, Bruce Brouwer bruce.brou...@gmail.com wrote: Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0

Re: Next release

Rats! It's not so simple as what I wrote. The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will

Re: Next release

I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad. On 13 July 2014 13:44,

Re: Next release

I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would

Re: Next release

Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release. No to renaming StatusLogger. It’s name is perfectly clear to me. Ralph On Jul 13, 2014, at 1:04 PM, Gary Gregory

Re: Next release

Bruce, My opinion is that in production in a web container the StatusLogger should ALWAYS be routed to stdout. The volume of output should normally be small if you are logging at Error. Second, in the ideal case you should only have a single log level, regardless of how many web applications

Re: Next release

Also, StatusLogger is final. Anyone who tries to implement a Logger based on that is going to have a hard time. StatusLogger is also intentionally primitive - you can’t do much filtering or routing to appenders, etc - so anyone who tries to use it for something is probably going to wonder why

Re: Next release

Also, I am against renaming StatusLogger as it will result in modifications to hundreds of files. Ralph On Jul 13, 2014, at 1:08 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking

Re: Next release

I agree with Ralph on all counts regarding StatusLogger. Really, anything that wants to store the StatusLogger output elsewhere is probably using standard out redirection. On 13 July 2014 15:34, Ralph Goers ralph.go...@dslextreme.com wrote: Also, I am against renaming StatusLogger as it will

Re: Next release

I'm all for making this more like a simple on/off switch. But the way things are setup right now, once you turn on the console logging, it can never be turned off. That is because once it is registered, nothing ever removes it. Are we ok with that? If we are, then I would like to remove all the

Re: Next release

I haven't studied StatusLogger in that much depth, but what you're saying sounds good. I agree with Ralph that this is for diagnostics and it's better to keep this simple. Sent from my iPhone On 2014/07/14, at 8:19, Bruce Brouwer bruce.brou...@gmail.com wrote: I'm all for making this more

Re: Next release

If it can't be turned off that doesn't sound right. You should be able to get to the listener and change its level so that nothing is logged. I guess you are meaning the listener can't be removed? For some reason I thought it could. Ralph On Jul 13, 2014, at 4:19 PM, Bruce Brouwer

Re: Next release

Should double check better. Should not be a real performance issue On Jul 13, 2014 7:35 PM, Remko Popma remko.po...@gmail.com wrote: I haven't studied StatusLogger in that much depth, but what you're saying sounds good. I agree with Ralph that this is for diagnostics and it's better to keep

Re: Next release

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

Re: Next release

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.brou...@gmail.com wrote: The listener can be removed, but nothing ever does. Right now it can never

Re: Next release

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

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,

Re: Next release

Brouwer bruce.brou...@gmail.com /divdivDate:07/13/2014 22:35 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next release /divdiv /divOk, the only test that didn't pass was the one testing for StatusLogger writing to a file. I removed that test

Re: Next release

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

Re: Next release

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

Re: Next release

case, someone will hit it. Unfortunately I have no time this weekend. Gary Original message From: Bruce Brouwer Date:07/11/2014 23:11 (GMT-05:00) To: Log4J Developers List Subject: Re: Next release I know I haven't had time to spend on this project lately, but I never

Re: Next release

Creating a branch won't hurt :-) Gary div Original message /divdivFrom: Bruce Brouwer bruce.brou...@gmail.com /divdivDate:07/12/2014 07:28 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next release /divdiv /divShall I make

Re: Next release

:07/11/2014 23:11 (GMT-05:00) To: Log4J Developers List Subject: Re: Next release I know I haven't had time to spend on this project lately, but I never finished off LOG4J2-609 https://issues.apache.org/jira/browse/LOG4J2-609. If you're itching to release this weekend, then I won't be able

Re: Next release

What about binary compatibility? Gary div Original message /divdivFrom: Remko Popma remko.po...@gmail.com /divdivDate:07/12/2014 08:31 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next release /divdiv /divI would really like

Re: Next release

: What about binary compatibility? Gary Original message From: Remko Popma Date:07/12/2014 08:31 (GMT-05:00) To: Log4J Developers List Subject: Re: Next release I would really like to do the 2.0 release vote this weekend. Bruce, based on what I've seen from the patch

Re: Next release

On Jul 12, 2014, at 7:04 AM, Gary Gregory garydgreg...@gmail.com wrote: What about binary compatibility? Gary Original message From: Remko Popma Date:07/12/2014 08:31 (GMT-05:00) To: Log4J Developers List Subject: Re: Next release I would really like to do the 2.0 release

Re: Next release

Hi, We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed. We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out. The only issue we had so far was about configuring async logger for

Re: Next release

Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release. On Jul

Next release

I would like to do the release for Log4j 2.0 this weekend. Are there any objections? Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Next release

No objection at all! I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631. Also, the site now has an empty section Custom Plugins under manual Extending Log4j. Shall we remove that before the release? Sent from my iPhone On 2014/07/11, at

Re: Next release

Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :) On 11 July 2014 03:58, Remko Popma remko.po...@gmail.com wrote: No objection at all! I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631. Also, the site now has an empty

Re: Next release

On Friday, July 11, 2014, Remko Popma remko.po...@gmail.com wrote: No objection at all! I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631. Done with these changes. Also, the site now has an empty section Custom Plugins under manual

Re: Next release

I know I haven't had time to spend on this project lately, but I never finished off LOG4J2-609 https://issues.apache.org/jira/browse/LOG4J2-609. If you're itching to release this weekend, then I won't be able to get this done. The solution I'm presenting is a little bit invasive in the API, but I

Re: Next release

Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next release /divdiv /divI know I haven't had time to spend on this project lately, but I never finished off LOG4J2-609. If you're itching to release this weekend, then I won't be able to get this done. The solution I'm presenting

RE: Next Release

/divdivFrom: Ralph Goers ralph.go...@dslextreme.com /divdivDate:06/19/2014 00:57 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Next Release /divdiv /divWe are overdue for a release. The only question I have is whether it should be rc2 or GA. 1

Re: Next Release

with RC 2 then we can release. There also one non trivial issue/feature I'll ask about ASAP on the ML. Gary Original message From: Ralph Goers Date:06/19/2014 00:57 (GMT-05:00) To: Log4J Developers List Subject: Next Release We are overdue for a release. The only question

Re: Next Release

: Ralph Goers Date:06/19/2014 00:57 (GMT-05:00) To: Log4J Developers List Subject: Next Release We are overdue for a release. The only question I have is whether it should be rc2 or GA. 1. Are there any open issues that are blockers to a GA release? 2. Is everyone comfortable with the state

Re: Next Release

trivial issue/feature I'll ask about ASAP on the ML. Gary Original message From: Ralph Goers Date:06/19/2014 00:57 (GMT-05:00) To: Log4J Developers List Subject: Next Release We are overdue for a release. The only question I have is whether it should be rc2 or GA

Re: Next Release

Original message From: Ralph Goers Date:06/19/2014 00:57 (GMT-05:00) To: Log4J Developers List Subject: Next Release We are overdue for a release. The only question I have is whether it should be rc2 or GA. 1. Are there any open issues that are blockers to a GA release? 2. Is everyone

Re: Next Release

I think we are actually missing out on a lot of community feedback by not releasing 2.0. Many people are waiting... If we want to make this release an RC release instead of GA, I can live with that, but then we should do our utmost to make the next release GA. If we want to avoid branching

Re: Next Release

by not releasing 2.0. Many people are waiting... If we want to make this release an RC release instead of GA, I can live with that, but then we should do our utmost to make the next release GA. If we want to avoid branching, then let's agree to only commit bug fixes, and no new features

Re: Next Release

Sounds good. Gary div Original message /divdivFrom: Remko Popma remko.po...@gmail.com /divdivDate:06/19/2014 19:37 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next Release /divdiv /divI think we are actually missing out

Re: Next Release

Original message From: Remko Popma Date:06/19/2014 19:37 (GMT-05:00) To: Log4J Developers List Subject: Re: Next Release I think we are actually missing out on a lot of community feedback by not releasing 2.0. Many people are waiting... If we want to make this release an RC release

Re: Next Release

:06/19/2014 19:37 (GMT-05:00) To: Log4J Developers List Subject: Re: Next Release I think we are actually missing out on a lot of community feedback by not releasing 2.0. Many people are waiting... If we want to make this release an RC release instead of GA, I can live with that, but then we

Re: Next Release

by not releasing 2.0. Many people are waiting... If we want to make this release an RC release instead of GA, I can live with that, but then we should do our utmost to make the next release GA. If we want to avoid branching, then let's agree to only commit bug fixes, and no new features

Re: Next Release

(GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Next Release /divdiv /divAbout outstanding issues: I'm aware of two things: changes to the site for the new logo (incl updating the home page announcement) and ensuring that the log4j-perf module

Re: Next Release

on a lot of community feedback by not releasing 2.0. Many people are waiting... If we want to make this release an RC release instead of GA, I can live with that, but then we should do our utmost to make the next release GA. If we want to avoid branching, then let's agree to only commit bug

Re: Next Release

with that, but then we should do our utmost to make the next release GA. If we want to avoid branching, then let's agree to only commit bug fixes, and no new features/refactoring to trunk until after GA. Thoughts? Sent from my iPhone On 2014/06/19, at 23:19, Gary Gregory garydgreg...@gmail.com wrote

Re: Next Release

. Gary Original message From: Remko Popma Date:06/19/2014 22:38 (GMT-05:00) To: Log4J Developers List Subject: Re: Next Release About outstanding issues: I'm aware of two things: changes to the site for the new logo (incl updating the home page announcement

Re: Next Release

nicely sort together. Gary Original message From: Remko Popma Date:06/19/2014 22:38 (GMT-05:00) To: Log4J Developers List Subject: Re: Next Release About outstanding issues: I'm aware of two things: changes to the site for the new logo (incl updating the home

Next Release

We are overdue for a release. The only question I have is whether it should be rc2 or GA. 1. Are there any open issues that are blockers to a GA release? 2. Is everyone comfortable with the state of the code for a GA release? For me, I am not aware of any blockers and I think the code is good.

Re: Next release of 2.0

and voice out real concerns. At best, he doesn't find much. If he needs more time, give more time. if there is something to fix, fix it now. But lets make the next release stable and a real 2.0. Because that will also start the discussion of eol log4j 1, finally. My 2 cent. :) Cheers

Re: Next release of 2.0

) 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

Re: Next release of 2.0

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

Re: Next release of 2.0

or another beta IMO. Once 2.0 is out you cannot unhinged that bell. Gary Original message From: Ralph Goers ralph.go...@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

Re: Next release of 2.0

: Ralph Goers ralph.go...@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

Re: Next release of 2.0

Original message From: Ralph Goers ralph.go...@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

Re: Next release of 2.0

: give Gary a few days, lets say 2 weeks to check the code base and voice out real concerns. At best, he doesn't find much. If he needs more time, give more time. if there is something to fix, fix it now. But lets make the next release stable and a real 2.0. Because that will also start

Re: Next release of 2.0

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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h

Re: Next release of 2.0

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

Re: Next release of 2.0

IMO. Once 2.0 is out you cannot unhinged that bell.  Gary Original message From: Ralph Goers ralph.go...@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

Re: Next release of 2.0

Goers ralph.go...@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

Re: Next release of 2.0

(GMT-05:00) To: Log4J Developers List 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

Re: Next release of 2.0

it RC or another beta IMO. Once 2.0 is out you cannot unhinged that bell. Gary Original message From: Ralph Goers ralph.go...@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

  1   2   >