> 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]
