In hindsight, I see another thread where asking this question is more appropriate. Ignore my reply here please and I'll ask the question elsewhere...
On Wed, Aug 26, 2026 at 12:02 PM Jason Gerlowski <[email protected]> wrote: > > > If we deprecated something on 10.0 and not 9.x because 9.x doesn't have the > > new method/class, my instinct is that we may remove the thing at any 10.x > > version (even 10.1) -- need not wait for 11. If we must wait for 11, I > > think this imposes too much of a burden on us. > > Can you please clarify with an example David? I'm not sure I follow... > > In general I worry about removing functionality in (e.g.) 10.2 vs. > 10.0. IMO it's valuable that those minor and bugfix releases are > easy, painless, and "safe" for folks to adopt. But I also don't know > I really understand the scenario you're describing, so maybe I'm just > misunderstanding... > > Best, > > Jason > > On Fri, Aug 21, 2026 at 9:07 AM Eric Pugh > <[email protected]> wrote: > > > > You may have noticed a flood of emails and notifications over the past few > > days, Serhiy has gone to town on the two lists that I put together of tasks > > in JIRA and generated a ton of PRs……. > > > > Thanks David and others for reviewing, it’s a reminder tha the bottleneck > > is the review side of things, even for something that seems as simple and > > mechanical as removing deprecated code! > > > > I’ve tried to move through the process the obviously simple ones, maybe a > > mite too quick at times, so will try to be cognizant of giving time for > > folks to review the changes. > > > > I’m also trying to stay on top of triggering the CI builds, adding the > > no-changelog labels, and of course, my favorite part, closing the JIRA > > issues. > > > > It’s exciting to see the sub tasks flipping from gray to green! > > > > Solr 10: https://issues.apache.org/jira/browse/SOLR-17931 > > Solr 11: https://issues.apache.org/jira/browse/SOLR-18369 > > > > I suspect over the next week or so we will see some instability in our > > Jenkins tests as all these various individual changes land together, > > however I am optimistic that come September, we’ll see a lot of tech debt > > paid down by cleaning up these deprecations. > > > > I’d love some additional eyes on reviewing these pr’s, even if you aren’t a > > committer. > > > > Eric > > > > > On Aug 21, 2026, at 9:00 AM, Eric Pugh <[email protected]> > > > wrote: > > > > > > We probably need something more concrete and written, maybe worth its own > > > thread? > > > > > >> On Aug 19, 2026, at 11:20 AM, David Smiley <[email protected]> wrote: > > >> > > >> Hey everyone: > > >> > > >> If we deprecated something on 10.0 and not 9.x because 9.x doesn't have > > >> the > > >> new method/class, my instinct is that we may remove the thing at any 10.x > > >> version (even 10.1) -- need not wait for 11. If we must wait for 11, I > > >> think this imposes too much of a burden on us. > > >> > > >> I guess if folks disagree with my assertion above, committers may choose > > >> to > > >> delete in 10.x *anyway* provided that the deprecated thing is "internal" > > >> (subjectively determined). For internal things, in my strong opinion, the > > >> deprecation is a courtesy and/or is equivalent to a TODO comment in a > > >> sense. We remove interal methods at will all the time without a > > >> deprecation or TODO! > > >> > > >> ~ David > > >> > > >> On Wed, Aug 19, 2026 at 9:53 AM Eric Pugh > > >> <[email protected] > > >> <mailto:[email protected]>> > > >> wrote: > > >> > > >> > Yeah, what I’ve found is that to help newer folks figure out HOW to > > >> > engage, we need to be better in our JIRA gardening… > > >> > > > >> > It helps unblock the “what should I do”…… > > >> > > > >> > > > >> > We more generally should be thinking about laying out great JIRA’s with > > >> > lots of well defined work…. Yeah, I know, that’s me pretending to be an > > >> > engineering manager or product manager ;-). And yeah, I’d rather write > > >> > code than write JIRAs…. This was at least a low hanging fruit. > > >> > > > >> > > > >> > > > >> > > > >> > > On Aug 19, 2026, at 9:39 AM, David Smiley <[email protected]> wrote: > > >> > > > > >> > > Thanks Eric! I reviewed your PR. > > >> > > Many of the JIRA deprecations aren't even JIRA-worthy (removing > > >> > > internal > > >> > > methods), but if it helps keep track of stuff then why not. IMO they > > >> > > can > > >> > > be removed whenever someone notices them and feel like doing it. At > > >> > > least > > >> > > the "since" info you are adding will really assist in identifying > > >> > > when > > >> > it's > > >> > > _safe_ to do so. > > >> > > > > >> > > On Tue, Aug 18, 2026 at 1:38 PM Eric Pugh < > > >> > [email protected]> > > >> > > wrote: > > >> > > > > >> > > > I noticed the tech debt of deprecated code seemed to be > > >> > > > increasing, and > > >> > > > wanted to get my arms around it a bit. Plus I’ve had folks ask how > > >> > > > they > > >> > > > can contribute, so hopefully this lays out some specific JIRA > > >> > > > tickets > > >> > that > > >> > > > folks can work on mostly independently. > > >> > > > > > >> > > > First off, I noticed that many of our deprecation annotations > > >> > > > don’t say > > >> > > > when something was deprecated. I’ve opened > > >> > > > https://github.com/apache/solr/pull/4750 > > >> > > > <https://github.com/apache/solr/pull/4750> < > > >> > https://github.com/apache/solr/pull/4750 > > >> > <https://github.com/apache/solr/pull/4750>> which tries to improve our > > >> > > > developer experience by going through mechanically (thanks Claude) > > >> > > > to > > >> > look > > >> > > > at each deprecation tag, and then go back and see when it was > > >> > deprecated, > > >> > > > and, if available, what the recommended upgrade path is. Hopefully > > >> > > > this > > >> > > > will make it easier for folks to pick up the work to deal with the > > >> > > > deprecations. > > >> > > > > > >> > > > Secondly, we had an old JIRA issue "Remove deprecated code from > > >> > > > Solr > > >> > 10" > > >> > > > https://issues.apache.org/jira/browse/SOLR-17931 > > >> > > > <https://issues.apache.org/jira/browse/SOLR-17931> < > > >> > https://issues.apache.org/jira/browse/SOLR-17931 > > >> > <https://issues.apache.org/jira/browse/SOLR-17931>> with Solr 10 > > >> > targeted > > >> > > > deprecations, it had a whole bunch of subtasks. All but 2 of them > > >> > > > were > > >> > > > complete, so I was thinking of closing it. But then, when I looked > > >> > > > at > > >> > the > > >> > > > updated deprecations since data, I realized there are bunch more > > >> > > > deprecations that could potentially land in Solr 10. > > >> > > > > > >> > > > Then, I took that same deprecations since data, and I opened up a > > >> > > > fresh > > >> > > > "Remove deprecated code from Solr 11" > > >> > > > https://issues.apache.org/jira/browse/SOLR-18369 > > >> > > > <https://issues.apache.org/jira/browse/SOLR-18369> < > > >> > https://issues.apache.org/jira/browse/SOLR-18369 > > >> > <https://issues.apache.org/jira/browse/SOLR-18369>> Mira issue. It has > > >> > 21 > > >> > > > specific sub tasks that would only land on the main branch. > > >> > > > > > >> > > > I’m hopeful that these various subtasks can each be independently > > >> > picked > > >> > > > up and worked on, and that some of the folks who are looking for > > >> > > > ways > > >> > to > > >> > > > contribute to Solr who see this email can pick some of these up! > > >> > > > > > >> > > > Eric > > >> > > > > > >> > > > Disclaimer > > >> > > > > > >> > > > The information contained in this communication from the sender is > > >> > > > confidential. It is intended solely for use by the recipient and > > >> > > > others > > >> > > > authorized to receive it. If you are not the recipient, you are > > >> > > > hereby > > >> > > > notified that any disclosure, copying, distribution or taking > > >> > > > action in > > >> > > > relation of the contents of this information is strictly prohibited > > >> > and may > > >> > > > be unlawful. > > >> > > > > > >> > > > This email has been scanned for viruses and malware, and may have > > >> > > > been > > >> > > > automatically archived by Mimecast, a leader in email security and > > >> > cyber > > >> > > > resilience. Mimecast integrates email defenses with brand > > >> > > > protection, > > >> > > > security awareness training, web security, compliance and other > > >> > essential > > >> > > > capabilities. Mimecast helps protect large and small organizations > > >> > > > from > > >> > > > malicious activity, human error and technology failure; and to > > >> > > > lead the > > >> > > > movement toward building a more resilient world. To find out more, > > >> > visit > > >> > > > our website. > > >> > > > > > >> > > > >> > Disclaimer > > >> > > > >> > The information contained in this communication from the sender is > > >> > confidential. It is intended solely for use by the recipient and others > > >> > authorized to receive it. If you are not the recipient, you are hereby > > >> > notified that any disclosure, copying, distribution or taking action in > > >> > relation of the contents of this information is strictly prohibited > > >> > and may > > >> > be unlawful. > > >> > > > >> > This email has been scanned for viruses and malware, and may have been > > >> > automatically archived by Mimecast, a leader in email security and > > >> > cyber > > >> > resilience. Mimecast integrates email defenses with brand protection, > > >> > security awareness training, web security, compliance and other > > >> > essential > > >> > capabilities. Mimecast helps protect large and small organizations from > > >> > malicious activity, human error and technology failure; and to lead the > > >> > movement toward building a more resilient world. To find out more, > > >> > visit > > >> > our website. > > >> > > > > > > > > Disclaimer > > > > The information contained in this communication from the sender is > > confidential. It is intended solely for use by the recipient and others > > authorized to receive it. If you are not the recipient, you are hereby > > notified that any disclosure, copying, distribution or taking action in > > relation of the contents of this information is strictly prohibited and may > > be unlawful. > > > > This email has been scanned for viruses and malware, and may have been > > automatically archived by Mimecast, a leader in email security and cyber > > resilience. Mimecast integrates email defenses with brand protection, > > security awareness training, web security, compliance and other essential > > capabilities. Mimecast helps protect large and small organizations from > > malicious activity, human error and technology failure; and to lead the > > movement toward building a more resilient world. To find out more, visit > > our website. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
