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