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.staldal@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 >>> 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
