Note that I said "for removed code". Clirr will also complain about methods added but I did not show that. Sadly, Clirr does not complain about methods being added via a change in inheritance. Clirr is oooooooold...
Gary On Thu, Sep 8, 2016 at 12:00 AM, Remko Popma <remko.po...@gmail.com> wrote: > Interesting, so Clirr does not detect the breaking change to > TriggeringPolicy. > > Sent from my iPhone > > On 2016/09/08, at 13:32, Gary Gregory <garydgreg...@gmail.com> wrote: > > FWIW, here is what Clirr finds for removed code: > > [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: > Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder > setFilter(org.apache.logging.log4j.core.Filter)' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: > Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder > setIgnoreExceptions(boolean)' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: > Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder > setLayout(org.apache.logging.log4j.core.Layout)' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: > Method 'public org.apache.logging.log4j.core.appender.ConsoleAppender$Builder > setName(java.lang.String)' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.appender.OutputStreamManager: > Method 'protected void close()' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.appender.WriterManager: > Method 'protected void close()' has been removed > [ERROR] 8001: org.apache.logging.log4j.core.async.DaemonThreadFactory: > Class org.apache.logging.log4j.core.async.DaemonThreadFactory removed > [ERROR] 7002: org.apache.logging.log4j.core.config.LoggerConfig: Method > 'public org.apache.logging.log4j.core.config.LoggerConfig > createLogger(java.lang.String, org.apache.logging.log4j.Level, > java.lang.String, java.lang.String, org.apache.logging.lo > g4j.core.config.AppenderRef[], > org.apache.logging.log4j.core.config.Property[], > org.apache.logging.log4j.core.config.Configuration, > org.apache.logging.log4j.core.Filter)' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.impl.ThrowableFormatOptions: > Method 'public java.util.List getPackages()' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.net.TcpSocketManager: Method > 'protected void close()' has been removed > [ERROR] 7002: org.apache.logging.log4j.core.util.Assert: Method 'public > java.lang.Object requireNonNull(java.lang.Object, java.lang.String)' has > been removed > [ERROR] 7002: org.apache.logging.log4j.core.util.Loader: Method 'public > java.lang.Class loadClass(java.lang.String)' has been removed > > Gary > > On Wed, Sep 7, 2016 at 9:29 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <boa...@gmail.com> wrote: >> >>> This is actually why I suggested making an spi package long ago in core >>> for public classes that would remain BC. Sadly, it's a little late for that >>> now. >>> >> >> It's never too late ;-) >> >> We could do that and call it 2.8 or surely for 3.0. BC for Core is not >> 100% guaranteed, we just try to make life not too painful for SPI providers. >> >> Gary >> >> >>> >>> On 7 September 2016 at 23:22, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <remko.po...@gmail.com> >>>> wrote: >>>> >>>>> Okay. >>>>> Shall we introduce an @Internal annotation? >>>>> >>>> >>>> Please no, everything in Core is internal. I think we need to start >>>> with English sentences before we get caught up on details of how to >>>> communicate that to users. >>>> >>>> Gary >>>> >>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 2016/09/08, at 12:52, Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>> I agree that util packages are out of scope for BC. That's especially >>>>> true in log4j-api where everything else has BC concerns. >>>>> >>>>> On 7 September 2016 at 21:14, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>> >>>>>> I do not think NullOutputStream.NULL_OUTPUT_STREAM is a good example >>>>>> because the Core util package is or should out of bounds for BC. I >>>>>> thought >>>>>> we had "agreed" on that. >>>>>> >>>>>> Gary >>>>>> >>>>>> On Wed, Sep 7, 2016 at 5:29 PM, Remko Popma <remko.po...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> We should make an effort not to break compatibility unless it's >>>>>>> unavoidable. There is usually a way to accomplish things without >>>>>>> breaking >>>>>>> BC. >>>>>>> >>>>>>> This is doubly true for plugins but should be our policy in general. >>>>>>> >>>>>>> We should not make breaking changes for aesthetic reasons. For >>>>>>> example, NullOutputStream.NULL_OUTPUT_STREAM would have been better >>>>>>> named INSTANCE, but this is one thing I would not change at this stage. >>>>>>> >>>>>>> One of the reasons people (I think on the Spark mailing list) >>>>>>> mentioned for putting off upgrading from Log4j 1.2 to Log4j 2 was >>>>>>> worries >>>>>>> we would make breaking changes. >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On 2016/09/08, at 8:03, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers < >>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>> >>>>>>>> We really need to document what we want to strive to maintain >>>>>>>> compatibility with in core. Basic components like Appenders and their >>>>>>>> managers, Filters, Layouts, & Lookups or pretty much any Plugin type >>>>>>>> would >>>>>>>> be at the top of my list. >>>>>>>> >>>>>>> >>>>>>> Bleh, then we need to mark methods in some @tag-way in Javadocs. >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>> On Sep 7, 2016, at 11:05 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma <remko.po...@gmail.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> We should do this before starting the 2.7 release. >>>>>>>>> If we are serious about being the replacement for Log4j 1.2 we >>>>>>>>> should not break user code for no good reason. >>>>>>>>> >>>>>>>> >>>>>>>> What does this have to do with 1.2? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Sep 7, 2016 at 7:25 AM, Remko Popma <remko.po...@gmail.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> I think that would be good. >>>>>>>>>> >>>>>>>>>> Based on the number of Jira tickets being filed we are beginning >>>>>>>>>> to see increased uptake. Programmatic configuration is used >>>>>>>>>> surprisingly >>>>>>>>>> often. Leaving the factory methods in with some reasonable default >>>>>>>>>> for the >>>>>>>>>> missing parameters ensures existing users can smoothly upgrade. >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On 2016/09/07, at 3:03, Matt Sicker <boa...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> All the commits that removed deprecated factory methods it sounds >>>>>>>>>> like. >>>>>>>>>> >>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory <garydgreg...@gmail.co >>>>>>>>>> m> wrote: >>>>>>>>>> >>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Should we revert those commits? There's still time. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What commit? Do you mean to add back factory methods? >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3 September 2016 at 01:12, Ralph Goers < >>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Perhaps we shouldn’t have. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> We've already removed several deprecated factories in this >>>>>>>>>>>>> upcoming release, though. >>>>>>>>>>>>> >>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal < >>>>>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I agree with Remko, let's keep them unless they are in the >>>>>>>>>>>>>> way. We can remove all of them in Log4j 3.0. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 1:31 AM, Remko Popma < >>>>>>>>>>>>>> remko.po...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It was mentioned on a mailing list or twitter conversation >>>>>>>>>>>>>>> with maintainers of another Apache project that one of the >>>>>>>>>>>>>>> reasons they >>>>>>>>>>>>>>> hesitate to migrate to Log4j is that they worry we will break >>>>>>>>>>>>>>> binary >>>>>>>>>>>>>>> compatibility. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Removing the factory methods just because we deprecated >>>>>>>>>>>>>>> them seems a bit harsh. >>>>>>>>>>>>>>> It's not like it's a huge maintenance effort to keep them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would not remove the deprecated factory methods unless >>>>>>>>>>>>>>> they actively prevent us from doing something we want to do. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Remko >>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/09/02, at 6:29, Ralph Goers < >>>>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, Java seems to have a policy of waiting at least 10 >>>>>>>>>>>>>>> years, if ever…. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Seriously, I don’t think 1 minor release is enough as that >>>>>>>>>>>>>>> might very well be the next release. I’d say 2 minor releases >>>>>>>>>>>>>>> and at least >>>>>>>>>>>>>>> 6 months. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 1, 2016, at 1:42 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think that when you add a builder and deprecate the >>>>>>>>>>>>>>> factory, you should remove it in the next 2.x release. >>>>>>>>>>>>>>> Otherwise, >>>>>>>>>>>>>>> deprecation has no point if there's no version with the >>>>>>>>>>>>>>> deprecation >>>>>>>>>>>>>>> specified. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 1 September 2016 at 13:40, Gary Gregory < >>>>>>>>>>>>>>> garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated by >>>>>>>>>>>>>>>> builders? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> [image: MagineTV] >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Mikael Ståldal* >>>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Magine TV* >>>>>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>>>>>>>>>>>> www.magine.com <http://www.magine.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained >>>>>>>>>>>>>> in this message. If you are not the addressee indicated in this >>>>>>>>>>>>>> message >>>>>>>>>>>>>> (or responsible for delivery of the message to such a >>>>>>>>>>>>>> person), you may not copy or deliver this message to anyone. In >>>>>>>>>>>>>> such case, >>>>>>>>>>>>>> you should destroy this message and kindly notify the sender >>>>>>>>>>>>>> by reply email. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>> <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> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>> <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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: garydgreg...@gmail.com | 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | 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> >>>>> >>>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | 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> >>> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | 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 >> > > > > -- > E-Mail: garydgreg...@gmail.com | 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 > > -- E-Mail: garydgreg...@gmail.com | 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
