I’ll defer the justification to those who were interested in the idea. I also lean toward 3.x, but I’ve already prepared most of the code necessary to back port this already. Otherwise, I’d also emphasize working on 3.0.0.
— Matt Sicker > On Apr 16, 2022, at 18:14, Gary Gregory <garydgreg...@gmail.com> wrote: > > I was ok w it either way but I do understand Ralph's POV. So maybe leave > 2.x alone in this department, unless there is an issue this would solve > that I missed. > > Gary > >> On Sat, Apr 16, 2022, 18:04 Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> The question isn’t can it be. The question is, should it be. At this point >> I don’t see why it should. It is necessary in 3.0 to accomplish some of the >> things we want to do there. But at this point I don’t think we should be >> doing major things to 2.x. >> >> Ralph >> >>>> On Apr 16, 2022, at 11:31 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> Features only available in DI have been asked about in a couple >> different situations already in 2.x development. I don’t plan on porting >> _all_ the changes I made in 3.x (such as the various startup optimizations, >> removal of deprecated code, and making all the existing system property >> based classes injectable), though I was hoping to at least enable some of >> the DI functionality for 2.18.0 as it should also make it a little easier >> to continue maintaining 2.x once we start making 3.x releases. >>> >>> I’ll open a PR with the general core of what I can port over without the >> deeper refactoring that was done in 3.x. Most of the relevant code here can >> be copied directly from master into this branch along with some updates to >> AbstractConfiguration. >>> — >>> Matt Sicker >>> >>>> On Apr 16, 2022, at 15:20, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>>> >>>> A) Why? >>>> B) I am not really a fan of this. I’d prefer to leave this major of a >> change for 3.0 unless there is a very compelling reason to do it sooner. >> I’d prefer to focus on getting 3.0 out sooner. >>>> >>>> Ralph >>>> >>>>> On Apr 16, 2022, at 7:14 PM, Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>> Hey all, I’m considering porting the new DI system back to 2.x (but >> put all in core as there’s no plugins module there) as there seems to be >> interest in using this earlier than in 3.0. While I’d be willing to do >> this, I wanted to see what anyone else thinks about the idea. I’d likely >> begin on a branch or fork, so it’d be nice to get another 2.17.x release >> out before I merged anything about this. >>>>> >>>>> Only real disadvantage of doing this is that the packages move around >> a little in 3.x, so I’ll have to add more duplicate annotations in 3.x >> afterwards to maintain compatibility. Although maybe I can start using the >> plugins package inside core in 2.x so it’s the same package name as in 3.x. >>>>> >>>>> — >>>>> Matt Sicker >>>> >>> >> >>
