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.com> >>>>>> wrote: >>>>>> >>>>>>> On Tue, Sep 6, 2016 at 12:31 PM, Matt Sicker <boa...@gmail.com> wrot >>>>>>> e: >>>>>>> >>>>>>>> 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.goers@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
