Interesting, so Clirr does not detect the breaking change to TriggeringPolicy. 

Sent from my iPhone

> On 2016/09/08, at 13:32, Gary Gregory <[email protected]> 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 <[email protected]> wrote:
>>> On Wed, Sep 7, 2016 at 9:26 PM, Matt Sicker <[email protected]> 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 <[email protected]> wrote:
>>>>> On Wed, Sep 7, 2016 at 9:17 PM, Remko Popma <[email protected]> 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 <[email protected]> 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 <[email protected]> 
>>>>>>> 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 <[email protected]> 
>>>>>>>> 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 <[email protected]> wrote:
>>>>>>>>> 
>>>>>>>>>> On Wed, Sep 7, 2016 at 1:02 PM, Ralph Goers 
>>>>>>>>>> <[email protected]> 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 <[email protected]> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Sep 7, 2016 at 11:41 AM, Remko Popma 
>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>> <[email protected]> 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 <[email protected]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> All the commits that removed deprecated factory methods it 
>>>>>>>>>>>>>> sounds like.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 6 September 2016 at 13:00, Gary Gregory 
>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker 
>>>>>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>>> Perhaps we shouldn’t have.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Sep 2, 2016, at 7:46 PM, Matt Sicker <[email protected]> 
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We've already removed several deprecated factories in this 
>>>>>>>>>>>>>>>>>> upcoming release, though.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 2 September 2016 at 06:28, Mikael Ståldal 
>>>>>>>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>>>>>>>>>>> <[email protected]> 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 
>>>>>>>>>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> When can we delete factory methods that are deprecated 
>>>>>>>>>>>>>>>>>>>>>>> by builders?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>>>>>> E-Mail: [email protected] | [email protected] 
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>>>>> Matt Sicker <[email protected]>
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Mikael Ståldal
>>>>>>>>>>>>>>>>>>> Senior software developer 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Magine TV
>>>>>>>>>>>>>>>>>>> [email protected]    
>>>>>>>>>>>>>>>>>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
>>>>>>>>>>>>>>>>>>> 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 <[email protected]>
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> Matt Sicker <[email protected]>
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> E-Mail: [email protected] | [email protected] 
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>> Matt Sicker <[email protected]>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> E-Mail: [email protected] | [email protected] 
>>>>>>>>>>> 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: [email protected] | [email protected] 
>>>>>>>>> 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: [email protected] | [email protected] 
>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Matt Sicker <[email protected]>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> E-Mail: [email protected] | [email protected] 
>>>> 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
>>> 
>>> 
>>> 
>>> -- 
>>> Matt Sicker <[email protected]>
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: [email protected] | [email protected] 
>> 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: [email protected] | [email protected] 
> 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

Reply via email to