Hello,
2014/1/3 Christian Grobmeier <grobme...@gmail.com> > On 3 Jan 2014, at 18:02, Scott Deboy 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. >> > > +1 > > I was not there back then, but i have seen the "too much bc" illness in > Commons. > Sorry, this is OT but I have to comment on this. It's not "too much bc" illness at Commons IMHO. Keeping an eye on bc between minor releases is a very good thing. It establishes rules, users can depend on (e.g. [1]). The problem is, when a project doesn't find the courage to make a major version change and break bc, because this may cause users not to use the newer version. I think users will switch to a newer release, if you give them something useful. At least that is what I would do. Scott suggested to make it possible to break API between 2.0 and 2.1 but not between 2.0 and 2.0.1. How is this different from releasing 2.0 this year and 3.0 next year? I mean, look at guava... They are at release 18.0 or something? Having that said: release 2.0, see how it turns out (I'm pretty sure it will stand up to its expectations). See how users feel about the API, fix anything that can be fixed without breaking BC and if there really is something that cannot be fixed, mark it as 3.0 and then have the courage to really do a 3.0. Benedikt [1] http://semver.org > > We are in Beta for a long time. From a community perspective I think its > really time to show that we trust in the new log4j2. > At the moment we have a pretty much unmaintained log4j1 and an officially > unstable log4j2. > > I think changes in log4j-api might be very rare. Under the hood we can > change things more often. If people use things behind the API, they must > also accept the fact that software is developing further. If they are > really concerned about changes they need to be involved. > > I gave a lot of talks on log4j2 in 2013 and i face a lot of questions > like: when will log4j2 be out. > While we might have some concerns, we should go "release early, often" and > show some trust in what we build. We have users who reports its great. I > use it myself without any problems. But as long as it has the beta label we > will not reach the wider developer community. > In the meantime it will become more difficult and difficult for us as > people start to migrate to other frameworks. > > You see, I have community concerns to release it now. And I have not heard > of any serious concerns against releasing it. > > My suggestion: 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 the discussion of eol log4j 1, finally. > > My 2 cent. :) > > Cheers, > Christian > > > > >> Scott >> >> On 1/3/14, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >>> What are contemplating changing in log4j-api? >>> >>> Ralph >>> >>> >>> On Jan 3, 2014, at 8:28 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>> On Fri, Jan 3, 2014 at 11:26 AM, Gary Gregory <garydgreg...@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.de...@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" <garydgreg...@gmail.com> wrote: >>>> On Thu, Jan 2, 2014 at 10:15 PM, Remko Popma <remko.po...@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.po...@gmail.com> >>>> wrote: >>>> What tweaks do you have in mind? API changes? >>>> >>>> >>>> On Fri, Jan 3, 2014 at 12:45 AM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>> On Thu, Jan 2, 2014 at 10:27 AM, Christian Grobmeier < >>>> grobme...@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.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 >>>> 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-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>>> --- >>>> http://www.grobmeier.de >>>> The Zen Programmer: http://bit.ly/12lC6DL >>>> @grobmeier >>>> GPG: 0xA5CC90DB >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> > > > --- > http://www.grobmeier.de > The Zen Programmer: http://bit.ly/12lC6DL > @grobmeier > GPG: 0xA5CC90DB > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
