Isn't this sort of why various libraries have been using the milestone release system instead of betas and RCs?
On Tuesday, 15 July 2014, Ralph Goers <rgo...@apache.org> wrote: > 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 <garydgreg...@gmail.com > <javascript:_e(%7B%7D,'cvml','garydgreg...@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.brou...@gmail.com > <javascript:_e(%7B%7D,'cvml','bruce.brou...@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.brou...@gmail.com >> <javascript:_e(%7B%7D,'cvml','bruce.brou...@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.go...@dslextreme.com >>> <javascript:_e(%7B%7D,'cvml','ralph.go...@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 <garydgreg...@gmail.com >>>> <javascript:_e(%7B%7D,'cvml','garydgreg...@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 <garydgreg...@gmail.com >>>> <javascript:_e(%7B%7D,'cvml','garydgreg...@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 <garydgreg...@gmail.com >>>>> <javascript:_e(%7B%7D,'cvml','garydgreg...@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.brou...@gmail.com >>>>> <javascript:_e(%7B%7D,'cvml','bruce.brou...@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 <boa...@gmail.com >>>>>> <javascript:_e(%7B%7D,'cvml','boa...@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.brou...@gmail.com >>>>>>> <javascript:_e(%7B%7D,'cvml','bruce.brou...@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 <boa...@gmail.com >>>>>>> <javascript:_e(%7B%7D,'cvml','boa...@gmail.com');>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Bruce Brouwer >>>>>> about.me/bruce.brouwer >>>>>> [image: Bruce Brouwer on about.me] >>>>>> <http://about.me/bruce.brouwer> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Bruce Brouwer >>>>> about.me/bruce.brouwer >>>>> [image: Bruce Brouwer on about.me] >>>>> <http://about.me/bruce.brouwer> >>>>> >>>>> >>>> >>>> > > > -- > E-Mail: garydgreg...@gmail.com > <javascript:_e(%7B%7D,'cvml','garydgreg...@gmail.com');> | ggreg...@apache.org > <javascript:_e(%7B%7D,'cvml','ggreg...@apache.org');> > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > -- Matt Sicker <boa...@gmail.com>
