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.com> >>>>>>> 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 >>>>>>>>>>>>>>> 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 <boa...@gmail.com> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mikael Ståldal >>>>>>>>>>> Senior software developer >>>>>>>>>>> >>>>>>>>>>> Magine TV >>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>> 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 <boa...@gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>> -- >>> 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
