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.
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] >>>>>>> <[email protected]> >>>>>>> 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 <[email protected]> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> [image: MagineTV] >>>>> >>>>> *Mikael Ståldal* >>>>> Senior software developer >>>>> >>>>> *Magine TV* >>>>> [email protected] >>>>> 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 <[email protected]> >>>> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> 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 <[email protected]> > >
